The FBI recently announced that BEC is a $55 billion scam. One thing you can do to protect against these bad actors is by implementing email authentication protocols.
SPF, DKIM, and DMARC are three must-have email authentication methods every business should use. Collectively, they prevent phishers from harming your customers (and your brand’s reputation).
Implemented correctly, they’ll boost your deliverability rate and customer experience. Left forgotten, your messages might end up in email purgatory: the spam folder (or not delivered at all).
Below, we’ll walk you through everything you need to know about DMARC vs. DKIM vs. SPF, and how they work together to protect your brand.
Key takeaways – SPF, DKIM, and DMARC each serve a different purpose, and you need all three to fully protect your domain from spoofing, phishing, and impersonation. – Most domains stall at p=none, leaving them vulnerable to attack and missing out on better deliverability. – DMARC enforcement increases trust, security, and inbox placement, but the path starts with visibility. |
What is SPF?
SPF (Sender Policy Framework) is an email validation protocol that enables domain owners to define a list of authorized email servers allowed to send emails on behalf of their domain. Domain owners publish SPF records in their Domain Name System (DNS) to specify which servers are legitimate senders of emails originating from their domain.
When an email is received, the recipient’s email server can check the SPF record of the sender’s domain to ensure that the email comes from an authorized source. SPF helps mitigate email spoofing and ensures that only authorized servers can send emails using a specific domain.
SPF is the oldest email authentication protocol, and it’s not designed to be a catch-all security method. Instead, it’s a simple step (of many) to protect your domain.
SPF authentication relies on the domain displayed in a message’s Return-Path field rather than the easily visible “From:” address. While that’s hand-dandy, most people rely on the information in the “From” field to determine the legitimacy of an email. In this case, SPF doesn’t help very much.

Real-world SPF use cases
Let’s say your company uses Salesforce and Mailchimp to send email. Without updating your SPF record to include both services, those emails might fail SPF checks, even though they’re legitimate. That’s why SPF maintenance is critical, especially in complex email ecosystems.
SPF pros
- Easy to set up (initially)
- Helps prevent direct spoofing of your domain
- Works with most inbox providers
SPF cons
- Only checks the Return-Path domain, not the visible “From” address
- Limited by the 10 DNS lookup limit
- Breaks easily if third-party senders change IPs
What is DKIM?
DomainKeys Identified Mail (DKIM) is an email authentication method that adds a digital signature to outgoing emails.
It ensures the authenticity and integrity of the message by allowing the recipient to verify that the email originates from a legitimate sender and has not been tampered with during transit. DKIM employs cryptographic keys to sign outgoing emails, and the recipient’s email server can verify the signature using the corresponding public key published in the sender’s domain’s DNS records.
DKIM provides an essential layer of trust, preventing email spoofing and guaranteeing message integrity. However, it has a few limitations that make it vulnerable (when used alone) to avoiding phishing attacks:
- Mismatched signatures
- Lost DKIM private key
- No connection to the mails servers required
If your email passes through a forwarding service or mailing list that changes the headers, the DKIM signature might fail, even if the original email was valid. That’s one reason why DKIM alone isn’t enough.
DKIM pros
- Verifies message integrity and authenticity
- Helps build sender reputation with inbox providers
- Enables BIMI (Brand Indicators for Message Identification) when combined with DMARC enforcement
DKIM cons
- Complex key management
- Doesn’t tell mail servers what to do with failed mail
- Can break in forwarding scenarios
What is DMARC?
Domain-based Message Authentication, Reporting, and Conformance (DMARC) empowers domain owners to instruct email receivers on how to handle unauthenticated emails sent from their domain. It combines the capabilities of DKIM and SPF and provides additional reporting mechanisms.
With DMARC, domain owners can specify how to handle emails that fail authentication:
- p=none: Take no action
- p=quarantine: Deliver to the spam folder
- p=reject: Don’t send the message at all
DMARC empowers organizations to gain greater control over their email domains and protect their brand reputation by reducing email fraud and phishing attacks.
DMARC pros
- Protects your domain from spoofing and impersonation
- Provides actionable reports to monitor authentication results
- Improves brand trust and deliverability
DMARC cons
- Requires correct SPF and/or DKIM setup
- Needs active management to reach enforcement
- Can be hard to implement without help (which is where Valimail comes in)
DMARC reporting
DMARC has a reporting mechanism that allows email receivers to inform the domain owner whether the received email has passed or failed authentication. The domain owner’s DMARC record can indicate where the receivers should send the reports.
These reports help the domain owner or their DMARC vendor identify who is using the domain to send emails. The valuable insights these reports provide enable domain owners to refine their email authentication policies, allowing them to authorize only trusted senders to send emails on behalf of the domain.
By leveraging this information, domain owners can strengthen their email security measures and ensure that only legitimate sources can send emails under their domain.
DMARC enforcement
Loosey-goosey DMARC policies aren’t enough to protect your brand, though—you need DMARC enforcement. DMARC enforcement ensures only legitimate email (that you’ve authorized) gets sent from your domains. Everything else is deleted or sent to the spam folder.
This happens by evolving your email program from a p=none policy to a p=quarantine or p=reject.
Internet Service Providers (ISPs) consider your sending domain’s reputation when making delivery decisions—and they take DMARC status into account. We have observed customers witnessing a remarkable increase in delivery rates for their marketing campaigns, ranging from 5 to 10%, upon transitioning to an enforcement policy.
Sadly, many companies that adopt DMARC fail to reach the enforcement stage. According to Valimail’s research, 75% to 80% of domains that have published a DMARC record face challenges in achieving enforcement. These challenges often arise from configuration errors or, more commonly, getting stuck at the p=none policy—sometimes for extended periods, spanning months or even years.
Operating in monitor mode, with a DMARC policy of p=none, does not protect your business. It simply tells you how your domain is sending emails without taking any action.
To see if your domain is at DMARC enforcement or not, use our free domain checker!
Check your
domain now
Enter your domain to see if it’s vulnerable to spoofing or if others are sending emails on your behalf. Instantly check your DMARC, SPF, and BIMI status with a detailed security report.
You’re not fully protected, learn more here.
Check your
domain now
Enter your domain to see if it’s vulnerable to spoofing or if others are sending emails on your behalf. Instantly check your DMARC, SPF, and BIMI status with a detailed security report.
You’re not fully protected, learn more here.
Check your
domain now
Enter your domain to see if it’s vulnerable to spoofing or if others are sending emails on your behalf. Instantly check your DMARC, SPF, and BIMI status with a detailed security report.
You’re not fully protected, learn more here.
Your Domain
Not protected AGAINST IMPERSONATION ATTACKS
DMARC NOT AT ENFORCEMENT
exampledomain1.com
Authentication Status for January 10, 2025
DMARC at Enforcement
SPF Record Configured
BIMI Ready
exampledomain1.com
Authentication Status for January 10, 2025
DMARC at Enforcement
SPF Record Configured
BIMI Ready
Why SPF, DKIM, and DMARC aren’t interchangeable
A lot of organizations think that using just SPF or DKIM is enough. It’s not. SPF, DKIM, and DMARC all solve a different part of the authentication puzzle:
- SPF checks where the email came from (sending server)
- DKIM checks what the email says (message integrity)
- DMARC checks who sent it (sender identity in the From field) and what to do if it fails
If you’re missing any one of these, attackers can slip through the cracks. For example, you could pass SPF but still get spoofed in the “From” address. Or pass DKIM but still get impersonated. Only DMARC checks for alignment between those systems and the visible sender domain.
How do DMARC, DKIM, and SPF work together?
DKIM and SPF work alone, but DMARC combines all three to protect your sending domain. Here’s how DMARC works:
- Domain owner publishes DMARC record: The domain owner (the organization that owns the sending domain) publishes a DMARC record in their DNS (Domain Name System) records. The DMARC record contains specific instructions for how receiving mail servers should handle emails that claim to originate from the domain.
- Incoming email arrives at recipient’s mail server: When an email is sent from a domain implementing DMARC, it reaches the recipient’s mail server.
- Mail server checks for DMARC record: The recipient’s mail server checks for the presence of a DMARC record in the sending domain’s DNS.
- SPF and DKIM authentication: The mail server then performs SPF and DKIM authentication checks on the incoming email. SPF verifies that the email comes from an authorized server, while DKIM verifies the email’s integrity and authenticity using digital signatures.
- DMARC policy check: If the email fails DMARC, the recipient’s mail server evaluates the policy specified in the DMARC record. The policy can be set to three possible values: “none,” “quarantine,” or “reject.”
- “None” policy: If the DMARC policy is set to “none,” the email is delivered as usual without additional action.
- “Quarantine” policy: If the DMARC policy is set to “quarantine,” the email is marked as potentially suspicious or sent to the recipient’s spam or junk folder.
- “Reject” policy: If the DMARC policy is set to “reject,” the email is rejected outright and not delivered to the recipient’s inbox.
- Reporting and feedback: DMARC includes reporting mechanisms where the recipient’s mail server sends feedback reports to the domain owner. These reports provide information about email authentication results, failed attempts, and other data that assists in monitoring and improving email security.
Purpose | How it works | Strengths | Limitations | |
---|---|---|---|---|
SPF | Verifies that the sending mail server is authorized to send on behalf of the domain. | Checks the sending server’s IP against the SPF record published in DNS. | Prevents domain spoofing at the server level; relatively easy to set up. | Does not validate the visible “From” address; limited against phishing on its own. |
DKIM | Ensures the email content and headers haven’t been altered; verifies sender identity via digital signature. | Adds a cryptographic signature to outgoing emails; verified using a public key in DNS. | Guarantees message integrity; builds trust with recipients. | Can be broken by message forwarding or header changes; requires key management. |
DMARC | Combines SPF and DKIM results to instruct receivers how to handle unauthenticated mail; provides reporting. | Evaluates SPF/DKIM results; applies policy (none, quarantine, reject); sends feedback reports to domain owner. | Gives domain owners control; provides visibility; reduces phishing and spoofing. | Requires SPF and/or DKIM to be effective; can be complex to configure and enforce. |
How to set up SPF, DKIM, and DMARC
Setting up SPF, DKIM, and DMARC is one of the most effective ways to protect your domain from impersonation and phishing. Each of these protocols plays a different role in email authentication, and all of them need to be published in your domain’s DNS settings.
If you have access to your domain’s DNS and know which services send email on your behalf, you are ready to get started.
How to set up SPF
- Identify all email senders.
- Start by listing every service that sends email using your domain. This might include marketing platforms, support tools, CRMs, and internal servers.
- Create your SPF record.
- An SPF record is a DNS TXT record that lists authorized sending servers. It usually starts with “v=spf1” and includes approved services.
Example:
v=spf1 include:_spf.google.com include:mail.zendesk.com ~all
- Add the SPF record to your DNS.
- Log in to your DNS provider and publish the SPF record as a TXT record for your domain.
- Check for the DNS lookup limit.
- SPF has a technical limit of ten DNS lookups. If you exceed this, your SPF check might fail. Avoid SPF flattening and consider using an infinite lookup like Valimail’s patented SPF for your record or removing unused services.
How to set up DKIM
- Enable DKIM in your email platform
- Platforms like Google Workspace, Microsoft 365, and Salesforce usually provide built-in DKIM support. Enable it in the settings or admin panel.
- Generate a DKIM key pair
- The platform will provide a TXT record containing your public DKIM key. The private key stays on the sending server.
- Publish your DKIM TXT record
- You will publish this record under a selector, such as:
default._domainkey.yourdomain.com
- You will publish this record under a selector, such as:
- Send a test email and check the headers
- Once your DKIM record is in place, send an email and look at the headers to confirm that it includes a valid DKIM signature.
How to set up DMARC
- Confirm SPF and DKIM are working
- DMARC requires at least one of these to be in place and aligned with your From address. If neither is working correctly, DMARC cannot function.
- Create a DMARC TXT record
- A basic DMARC record in monitoring mode might look like this:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
- A basic DMARC record in monitoring mode might look like this:
- Publish your DMARC record
- Add the TXT record to your DNS under this subdomain:
_dmarc.yourdomain.com
- Add the TXT record to your DNS under this subdomain:
- Monitor reports and prepare for enforcement
- Use Valimail Monitor to see which services are sending on your behalf, and which ones are failing authentication. Once you have visibility, you can confidently move to a quarantine or reject policy.
How to check if an email has passed SPF, DKIM, and DMARC
Want to know if an email passed SPF, DKIM, and DMARC checks? You can check it yourself since it’s all in the email headers.
Here’s how to do it:
1. Open the full email headers
Every mailbox provider hides headers in a different spot. Look for something like:
- Gmail: Click the three dots in the top right of the message > Show original
- Outlook: Click File > Properties > look in the Internet headers section
- Apple Mail: View > Message > All Headers
Regardless of what mailbox provider you’re using, look for the “Authentication-Results” section.
2. Look for SPF, DKIM, and DMARC results
In the headers, you’ll find lines like this:
Authentication-Results: spf=pass smtp.mailfrom=example.com;
dkim=pass header.d=example.com;
dmarc=pass (p=reject) header.from=example.com;
Each line tells you whether the message passed or failed that authentication check:
spf=pass
means the sending server was authorized.dkim=pass
means the message was signed and verified.dmarc=pass
means either SPF or DKIM passed and aligned with the visible “From” domain — and the message followed DMARC policy.
3. Use an email authentication solution
If you’re not into digging through raw headers, we’ve got you covered with two free solutions.
- Use our free Domain Checker to see if your domain is protected.
- Or use Valimail Monitor to get continuous visibility into your SPF, DKIM, and DMARC posture across all your senders.
Get started with domain visibility
If you’re serious about protecting your brand, improving email deliverability, and stopping phishing attacks at the source, you need more than one protocol.
You need all three: SPF, DKIM, and DMARC.
They form the foundation of Zero Trust email authentication: verifying who sends your email, what they send, and how it gets delivered.
Before you can stop impersonation and phishing attacks, you need to see how your domain is being used. That’s where it starts.
With Valimail Monitor, you get instant visibility into your domain’s email activity: who’s sending, what’s authenticated, and what’s at risk. No credit cards or free trials required.
Check your domain and uncover all of your senders by name:
Frequently asked questions about SPF, DKIM, and DMARC
Do I need DMARC if I already have SPF and DKIM?
Yes. SPF and DKIM don’t define any sort of enforcement action or policy. DMARC is the only protocol that tells inboxes what to do with failed messages and gives you visibility through reports.
Can I use DMARC without DKIM or SPF?
No, not if you send email messages and want those messages delivered successfully. DMARC requires at least one of SPF or DKIM to pass and align with the “From” domain. (The exception here is for domains that don’t send mail; you can lock them down with DMARC, without implementing SPF or DKIM.)
What’s the most important protocol to start with?
Start with SPF and DKIM so you can publish a DMARC record in monitor mode (p=none). Then work toward DMARC enforcement (p=quarantine or p=reject).
Where are SPF, DKIM, and DMARC records stored?
SPF, DKIM, and DMARC records are published in your domain’s DNS (Domain Name System). DNS is like the Internet’s address book: it helps direct traffic by matching domain names (like yourcompany.com
) to IP addresses, so users don’t have to memorize long strings of numbers.
But DNS does more than route traffic. It also stores important information about your domain, including email authentication settings.
SPF, DKIM, and DMARC records are stored as TXT records in DNS. TXT records let domain owners attach plain-text data to their domain, and email authentication protocols use them to tell inbox providers who’s authorized to send mail, how to validate it, and what to do if something looks suspicious.
In other words: DNS isn’t just for websites. It’s also how your domain tells the world what legitimate email looks like.
Do I actually need to implement SPF, DKIM, and DMARC to send email?
Yes, if you are a bulk sender, Microsoft, Google, Yahoo, and Apple all require SPF, DKIM, and DMARC to be set up and enabled in order to send email. Learn more about these requirements here.