SPF, DKIM and DMARC help prevent attackers sending email that falsely claims to come from your business. SPF identifies authorised sending infrastructure, DKIM verifies a cryptographic signature, and DMARC connects those checks to the visible sender address and requests how failed messages should be handled.
Publishing the records alone is insufficient: alignment and enforcement determine whether DMARC protects the visible sender identity against direct spoofing. These controls also leave gaps, including messages sent through compromised accounts, so start with what each protocol proves.
Key Takeaways
- SPF checks whether the sending server is authorised for the envelope sender, DKIM verifies a signature on message content, and DMARC connects those results to the visible From address.
- DMARC passes when at least one of SPF or DKIM passes and aligns with the visible From address. Its policy applies to messages that fail DMARC, so
p=noneprovides reporting visibility but doesn’t request enforcement. - Inventory every legitimate sending service, publish the records through the authoritative DNS provider, and test each sending route before tightening DMARC. Keep a single SPF policy for the domain.
- SPF, DKIM and DMARC reduce direct spoofing of protected domains, but they don’t stop lookalike addresses or fraudulent email sent through a compromised account. Account security and payment verification remain necessary.
What SPF, DKIM and DMARC actually check
These are email authentication standards configured through DNS, rather than interchangeable security filters. Each supplies different evidence about a message, and none establishes that its contents or payment instructions are trustworthy.
SPF identifies authorised sending infrastructure
Sender Policy Framework (SPF) lists the servers and IP addresses authorised to send for an organisation. Receiving servers compare the connecting server’s IP address against its SPF policy.
The important distinction is which address SPF checks. It normally evaluates the envelope sender address, associated with the Return-Path, rather than the address displayed in Outlook’s From field.
An SPF pass therefore doesn’t, by itself, prove that the visible sender is genuine. That distinction matters when assessing business email compromise, where a familiar-looking sender can influence payment decisions.
DKIM verifies a signature over message content
DomainKeys Identified Mail (DKIM) uses a private key held by the sending service to sign selected headers and message content. The receiving server retrieves the corresponding public key through the supplied configuration.
Successful verification shows that the signed content hasn’t changed since signing and links it to the identity in the DKIM record. It doesn’t establish that the sender’s account is uncompromised.
Mail providers normally generate and manage the key pair. Publish their supplied records; never publish the private key.
How DMARC alignment prevents direct domain spoofing
Domain-based Message Authentication, Reporting and Conformance (DMARC) connects authentication results to the address shown in the visible From field. It also publishes handling instructions and lets owners request authentication summaries.
A passing check must also align
DMARC passes when at least 1 authentication method both passes and aligns: SPF or DKIM. A failed SPF check doesn’t automatically mean DMARC fails if aligned DKIM succeeds.
Under default relaxed alignment, the authenticated identifier and visible From address can belong to the same organisation. Strict alignment requires an exact match.
A marketing service can pass SPF using its own identifier yet fail DMARC for your visible address. Configuring DKIM to use the name in your From address can provide the required alignment.
The policy determines the requested handling
DMARC policies apply to messages that fail DMARC, not every message that fails either underlying check.
| Policy | Requested handling | Practical use |
|---|---|---|
p=none | No DMARC-specific enforcement action | Observe authentication results |
p=quarantine | Treat failing messages as suspicious, commonly placing them in spam | Introduce enforcement |
p=reject | Reject failing messages | Block direct domain spoofing |
Receiving services retain discretion and apply their own security policies. A monitoring policy doesn’t disable their spam filters, but it doesn’t request spoofing enforcement either.
A published DMARC record with
p=noneprovides visibility, not an instruction to block impersonation.
Why Google and Yahoo require all 3
Google and Yahoo began introducing stronger bulk-sender authentication requirements in February 2024. Bulk senders need SPF, DKIM and DMARC, with at least a monitoring policy and the alignment needed for DMARC to pass.
Google’s sender guidelines introduced the requirements on 1 February 2024 for senders exceeding 5,000 daily messages to personal Gmail accounts. Yahoo’s sender requirements also require bulk senders to authenticate with both SPF and DKIM and pass DMARC.
These requirements address forged identities and unauthenticated traffic. They don’t guarantee inbox placement.
Treat authentication as one item on a deliverability checklist alongside sending reputation, complaint rates, unsubscribe requirements and recipient consent. A technically authenticated cold email campaign can still be filtered or rejected. Smaller senders also benefit from protection, even where a bulk-sender threshold doesn’t apply.
Identify the DNS host and every sending service
Authentication records belong in the authoritative service for the sending domain. The registrar, a separate provider or a managed IT provider may operate it, rather than the company hosting email.
DNS records have different roles
MX records tell other systems where to deliver incoming email. SPF, DKIM and DMARC support authentication; changing MX records does not configure them.
SPF and DMARC policies are published as TXT records. DKIM public keys are normally available through TXT records, but some providers use CNAME records that point to provider-managed keys. Microsoft 365 uses this approach.
Inventory senders before changing policy
Identify every legitimate sender before starting the authentication setup. Check Exchange Online, CRM platforms, marketing systems, payroll tools, ticketing systems, website forms and devices that send email. Record each service’s From address, envelope sender and DKIM signing identity.
Missing a legitimate source can turn a sensible security change into a delivery failure. Include occasional senders, such as annual renewal notices, rather than relying on a single day’s traffic.
An Office 365 assessment can place authentication alongside mailbox forwarding, permissions and other email security settings.
How to configure SPF, DKIM and DMARC in Microsoft 365
Use this setup for each custom sending domain. Adding it to Microsoft 365 doesn’t complete authentication. The practical sequence is SPF, DKIM, then DMARC, followed by tests of every legitimate sending route.
- Publish or update SPF. For a sender using only Exchange Online, Microsoft’s standard TXT value is
v=spf1 include:spf.protection.outlook.com -all. Publish it at the root, commonly shown as@. Add other authorised services to the same policy rather than creating another SPF record. - Enable custom-domain DKIM. In the Microsoft Defender portal’s email authentication settings, select the sending name and retrieve its 2 selector CNAME records. Publish the exact tenant-specific targets, then enable signing once the records are recognised. Microsoft’s DKIM configuration guidance explains this process.
- Publish a monitoring DMARC record. Create the TXT record at
_dmarcbeneath the name. Start withv=DMARC1; p=noneand add arua=mailto:reporting destination for an existing, monitored mailbox or reporting service. Reports require that reporting instruction. - Test delivery and authentication. Send through each authorised service to external recipients. Inspect the Authentication-Results header for SPF, DKIM and DMARC outcomes, including the names evaluated. Use Exchange message trace to investigate Microsoft 365 delivery outcomes.
Our Microsoft 365 support services cover email configuration and security support alongside ongoing administration. Keep responsibility for record changes explicit, even when another supplier operates the sending tool.
Read reports before enforcing DMARC
Aggregate DMARC summaries show authentication activity reported by participating receivers. They can show source IP addresses, message counts, authentication results and the handling applied, including attempts that receivers rejected.
Separate legitimate failures from unauthorised traffic
Aggregate summaries normally arrive as XML, often compressed. A reporting service can group sources and results, but the business still needs to identify which systems are authorised.
A failing source may be an attacker, a forgotten application, a forwarding service or an incorrectly configured supplier. These results don’t establish intent, and they don’t usually contain complete message bodies.
Forwarding can break SPF because the connecting server changes. DKIM may survive forwarding, but message modifications can invalidate its signature.
Tighten policy after correcting legitimate senders
Move towards quarantine and then reject after legitimate sources achieve aligned authentication. Cover normal operational cycles, including invoicing, payroll and infrequent campaigns, before treating the inventory as complete.
Microsoft’s DMARC guidance describes policy configuration and deployment considerations. Set progression criteria based on identified senders and resolved failures, rather than leaving monitoring enabled indefinitely.
Where a legitimate message fails, fix its sending route or alignment. Don’t weaken the organisation’s policy merely to accommodate 1 unconfigured application.
Maintain authentication whenever sending arrangements change
Authentication needs change control, not just an initial installation. Review the records whenever a sending tool, mailbox provider, subdomain or hosting arrangement changes.
Use this deliverability checklist to test sending routes and maintain records:
- Configure secondary sending services before warm-up or outbound campaigns begin, and correct failed SPF, DKIM or DMARC tests before sending.
- Maintain only 1 SPF policy and keep processing within SPF’s limit of 10 DNS-triggering lookups.
- Remove retired sending services and complete DKIM key rotation through the provider’s supported process.
- Preserve authentication records during migrations, then test each live sending route after a DNS change.
- Assign an owner for DMARC reports, delivery failures and approval of new senders.
Document the expected authentication results as well as the record values. A record can remain syntactically valid after the service it authorises is no longer needed.
What email authentication cannot prevent
SPF, DKIM and DMARC reduce direct spoofing of protected domains. They do not stop attackers registering a lookalike address or putting a director’s name in the display-name field.
They also do not make a compromised mailbox safe. Email sent through a genuine account can pass authentication while carrying fraudulent instructions. Apply phishing-resistant authentication, account monitoring, appropriate permissions and Microsoft 365 anti-phishing configuration alongside domain protection.
Payment procedures remain necessary. Confirm changed bank details using a trusted telephone number already held on file, rather than a number supplied in the email requesting the change.
Treat authentication failures as evidence to investigate, not a reason to create broad allow-list exceptions. Overriding filtering can expose users to unrelated threats, even when the immediate aim is to restore a supplier’s email delivery.
Frequently Asked Questions
What does DMARC alignment mean?
Alignment means that an authenticated SPF or DKIM identity matches the domain in the visible From address. DMARC passes when at least one of those methods both passes its authentication check and aligns.
Does a DMARC policy of p=none block spoofed email?
No. p=none requests no DMARC-specific enforcement, although a reporting address can receive aggregate summaries of authentication results. Receiving services still apply their own security policies.
Can SPF, DKIM and DMARC stop all email spoofing?
They reduce direct spoofing of a protected domain, but they don’t stop attackers using lookalike addresses or a person’s name in the display-name field. A compromised mailbox can also send fraudulent messages that pass authentication.
When should I move to a stricter DMARC policy?
First identify all legitimate sending services, review reports and correct authentication or alignment failures. Move to quarantine and then reject after legitimate routes pass and you have checked infrequent sending cycles such as payroll and annual notices.
Put domain protection under change control
The useful outcome is aligned authentication with an enforced DMARC policy, supported by reporting and a maintained sender inventory. Having 3 records present does not establish that outcome.
Review legitimate sending routes before tightening enforcement. Keep account protection and payment verification separate, because authenticated email can still be fraudulent.
Speak to our team about business email security support to review email authentication, Microsoft 365 settings and the changes needed to protect legitimate delivery.
