On this page
Definition
SPF, DKIM and DMARC are email authentication records stored in DNS. They help receiving mail servers check whether an email really came from an authorised sender, whether it was altered in transit, and what to do if the message fails those checks.
These records can improve email deliverability and reduce spoofing risk, but they do not guarantee inbox placement. Spam filtering also depends on sender reputation, email content, user behaviour and provider rules.
Key Takeaways
- SPF tells receiving mail servers which systems are authorised to send email for your domain.
- DKIM adds a digital signature so the receiving server can check that the message has not been changed after it was sent.
- DMARC connects SPF and DKIM to a policy, helping domain owners monitor, quarantine or reject suspicious email.
Quick Explanation
Why Email Authentication Matters
The Three Email Authentication Records
SPF, DKIM and DMARC are often discussed together, but each record answers a different question during email verification.
- SPF
- Sender Policy Framework is a DNS TXT record that lists the mail servers and platforms authorised to send email for a domain. For example, it may authorise Microsoft 365, a website server, an invoicing platform or a marketing email platform.
- DKIM
- DomainKeys Identified Mail uses a private signing key and a public DNS record to verify that a message has not been altered after sending. The public key is published in DNS, while the sending platform signs outgoing messages.
- DMARC
- Domain-based Message Authentication, Reporting and Conformance uses SPF and DKIM results with alignment checks. It tells receiving servers whether to monitor, quarantine or reject messages that fail authentication.
How It Works
How Receiving Mail Servers Check an Email
Email authentication happens behind the scenes each time a receiving mail server evaluates a message. The exact checks vary by provider, but the broad process looks like this.
-
The receiving server checks SPF
The server looks up the sender domain’s SPF record in DNS and checks whether the sending IP address or sending service is authorised. If the message came from an approved source, SPF can pass.
-
The receiving server checks DKIM
The server looks for a DKIM signature in the email headers. It then uses the public key published in DNS to confirm that the signature is valid and that important parts of the message were not changed.
-
The receiving server applies DMARC
DMARC checks whether SPF or DKIM passed and whether the authenticated domain aligns with the visible From address. It then applies the domain owner’s policy, such as monitoring, quarantine or rejection.
Example DNS Records for Email Authentication
The records below are simplified examples only. Your actual SPF, DKIM and DMARC values depend on your email provider, domain setup and connected sending platforms.
@ TXT "v=spf1 include:spf.protection.outlook.com -all"
selector1._domainkey TXT "v=DKIM1; k=rsa; p=PUBLICKEYGOESHERE"
_dmarc TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=s; aspf=s"Do not copy these records directly. Incorrect DNS records can interrupt email delivery or cause legitimate messages to fail authentication.
Authentication Is Not the Same as Inbox Placement
Business Impact
How SPF, DKIM and DMARC Affect a Business
Common SPF, DKIM and DMARC Mistakes
Many email deliverability issues come from small DNS mistakes. These are common problems we look for during email and DNS reviews.
Adding multiple SPF records to the same domain
Do this instead
A domain should normally have one SPF record. If you use several sending platforms, they need to be combined into a single valid SPF record rather than published as separate records.
Setting DMARC to reject before checking legitimate senders
Do this instead
A strict DMARC policy can be useful, but it should be introduced carefully. Starting with monitoring can help identify approved platforms before quarantine or reject policies are applied.
Forgetting website forms and third-party platforms
Do this instead
Email authentication should account for every legitimate sender, including Microsoft 365, website servers, CRMs, booking systems, invoicing tools and email marketing platforms where they are used.
Troubleshooting Email Authentication Problems
If your business emails are being rejected, marked as spam or failing authentication checks, the cause is often found in DNS, email platform settings or third-party sending tools.
Emails from Microsoft 365 work, but website form emails fail
Likely cause
The website server or form sending service may not be authorised in SPF, or it may not be signing with DKIM. The visible From address may also fail DMARC alignment.
Solution
Review the sending method used by the website and configure it through an authenticated mail service where appropriate. Check SPF, DKIM and DMARC alignment before changing live records.
A marketing platform says the domain is not authenticated
Likely cause
The required DNS records may be missing, entered incorrectly or still propagating. Some platforms require CNAME records for DKIM rather than a TXT record.
Solution
Compare the platform’s required records with the live DNS zone. Allow for DNS propagation, then re-check verification inside the sending platform.
Legitimate emails fail after a DMARC policy change
Likely cause
A strict DMARC policy may have been applied before all approved senders were configured correctly. Some systems may pass SPF or DKIM but fail domain alignment.
Solution
Review DMARC reports where available, identify legitimate failed sources, correct authentication, then adjust the DMARC policy in a controlled way.
Email Authentication Review Checklist
Use this checklist when reviewing SPF, DKIM and DMARC for a business domain. It is especially useful before changing email providers, launching a new website or adding a third-party sending platform.
-
List every system that sends email for the domain
Include Microsoft 365 or another mailbox provider, the website, CRM, invoicing tools, booking systems, marketing platforms and support software.
-
Check that DNS records are valid and not duplicated
Confirm there is only one SPF record, DKIM records match the sending provider’s requirements, and the DMARC record is syntactically correct.
-
Review DMARC policy and reporting before tightening enforcement
Monitoring can help identify legitimate email sources before moving to quarantine or reject policies. This reduces the risk of blocking valid business email.
Benefits and Limits of SPF, DKIM and DMARC
What They Help With
- They help receiving mail servers verify whether a message is likely to be legitimate.
- They reduce the risk of basic domain spoofing and support clearer handling of failed messages.
- They provide a stronger technical foundation for business email deliverability.
What They Do Not Guarantee
- They do not guarantee that every message will reach the inbox.
- They do not prevent all phishing, especially attacks using lookalike domains.
- They do not replace good email content, sender reputation management or secure account practices.
When to Review
When Should SPF, DKIM and DMARC Be Checked?
Our Approach
How We Configure Business Email Authentication
SPF, DKIM and DMARC FAQs
These questions cover the practical concerns businesses often have when setting up or reviewing email authentication.
Do I need all three records?
Can SPF, DKIM and DMARC stop all spam?
Can incorrect DNS records break my email?
Need Help With Email Authentication?
If your emails are landing in spam, your DNS records are unclear or you are planning an email migration, we can review your setup and help configure SPF, DKIM and DMARC correctly.