SPF, DKIM and DMARC are three separate email-authentication controls published or referenced through your domain’s DNS. They do not make every email trustworthy, but together they help receiving mail systems verify who is allowed to send for your domain and how to handle messages that fail those checks.
If your business sends invoices, password resets, support replies or newsletters, this setup affects both security and deliverability. The safest approach is to inventory all senders, configure SPF and DKIM, monitor DMARC reports, and only then move toward enforcement.
SPF: which servers may send for your domain?
Sender Policy Framework (SPF) is a TXT record that lists the mail systems authorized to send using your domain. A receiving server compares the message’s envelope sender with that policy.
A simplified record can look like this:
v=spf1 include:_spf.examplemail.com -all
Do not copy that value. Your real record must reflect your actual email provider, website forms, CRM, help desk and marketing service.
Common SPF mistakes
- Publishing more than one SPF record for the same hostname.
- Forgetting a legitimate sender such as a website or newsletter tool.
- Using
+all, which effectively authorizes everyone. - Creating too many nested DNS lookups.
- Assuming SPF alone protects the visible From address.
DKIM: was the message signed and unchanged?
DomainKeys Identified Mail (DKIM) adds a cryptographic signature to outgoing mail. The sending platform holds a private key; you publish the matching public key in DNS under a selector such as selector1._domainkey.example.com.
The recipient verifies the signature. A valid signature shows that the message was signed by a system authorized for that DKIM domain and that signed parts were not altered in transit.
Generate DKIM keys inside the email service, not with a random record copied from another tutorial. Google recommends a 2048-bit key when the DNS provider supports it; Gmail requires at least 1024 bits for mail sent to personal Gmail accounts.
DMARC: alignment, policy and reports
Domain-based Message Authentication, Reporting and Conformance (DMARC) checks whether SPF or DKIM passes and aligns with the domain visible in the From header. It also tells receiving systems what policy the domain owner requests for failures.
A monitoring record may look like:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
At p=none, you receive reports without asking receivers to quarantine or reject failures. After reviewing every legitimate sender, you can consider p=quarantine and eventually p=reject. Moving to enforcement too early can block genuine mail.
How the three controls work together
| Control | Main question | Published at |
|---|---|---|
| SPF | Is this sending server authorized? | Root domain or sending hostname |
| DKIM | Does the cryptographic signature verify? | Selector._domainkey |
| DMARC | Does SPF or DKIM align with the visible From domain, and what should happen if not? | _dmarc |
Google’s current email sender guidelines explain that a message can pass DMARC through aligned SPF or aligned DKIM. Using both gives better resilience.
Safe setup order
- Inventory every sender. Include employee mailboxes, website forms, billing, support, marketing and monitoring tools.
- Publish one accurate SPF record. Merge authorized sources instead of creating separate SPF records.
- Enable DKIM in each provider. Add each provider’s unique selector and test a signed message.
- Start DMARC at monitoring. Send aggregate reports to a dedicated, protected mailbox or reporting service.
- Review reports. Identify legitimate systems, forwarded mail and suspicious sources.
- Tighten gradually. Use a limited percentage or quarantine policy before moving to reject.
- Keep monitoring. New tools and forgotten website forms can silently become unauthorized senders.
How to test without guessing
Send messages from every real source to test inboxes. In Gmail, open “Show original” and check the SPF, DKIM and DMARC results. Also inspect the From domain, return path and DKIM signing domain for alignment. DNS tools can confirm that records are published, but an actual delivered message verifies the full sending path.
If you need a refresher on TXT records, read SiteChai’s guide to A, CNAME, MX and TXT records. For a domain-based mailbox, compare SiteChai’s business email options and the guide to setting up professional business email.
Frequently asked questions
Do I need all three records?
Most business domains should use SPF, DKIM and DMARC. SPF and DKIM provide authentication signals; DMARC connects them to the visible From domain and adds policy and reporting.
Will DMARC stop all spoofing?
No. It helps receivers handle unauthorized use of your exact domain, but attackers can use lookalike domains, compromised legitimate accounts or display-name tricks. Staff awareness and account security still matter.
Why did legitimate mail fail after I changed DMARC?
A sender may be missing from SPF, not signing with DKIM, or using domains that do not align with the visible From address. Return to monitoring, identify the source and fix the sending configuration before enforcing again.
Last fact-check: 24 August 2026. Record values are provider-specific; use the values generated by your actual email services.
