SPF, DKIM, and DMARC: Getting to Enforcement Without Breaking Mail Flow

SPF, DKIM and DMARC are the foundations of modern email authentication.

Together, they help receiving mail systems determine whether a message claiming to come from your domain was sent through an authorised service and whether the visible sender address can be trusted.

However, publishing a DMARC record is the easy part.

The difficult part is moving from a monitoring policy such as p=none to full enforcement with p=reject without accidentally blocking legitimate messages from marketing platforms, customer-management systems, scanners, websites, payroll tools and third-party suppliers.

The safest approach is not to switch DMARC enforcement on overnight. It is to discover every genuine sender, correct authentication and alignment problems, test gradually and then increase protection in controlled stages.

Microsoft recommends configuring SPF and DKIM before DMARC, beginning with monitoring and working towards p=reject after legitimate mail has been verified. 

What Do SPF, DKIM and DMARC Do?

These three technologies work together, but each performs a different job.

None of them should be treated as a complete solution by itself.

Microsoft specifically advises using all three because SPF or DKIM alone is not enough to prevent spoofing of a Microsoft 365 domain. 

What Is SPF?

Sender Policy Framework, or SPF, is a DNS-based list of systems authorised to send email using a domain in the SMTP envelope sender.

A simplified Microsoft 365 SPF record might look like this:

v=spf1 include:spf.protection.outlook.com -all

This tells receiving mail systems that Microsoft 365 is authorised to send mail for the domain.

Other legitimate senders may also need to be represented, including:

• Marketing platforms
• Customer relationship management systems
• Website contact forms
• Finance and invoicing applications
• Help-desk systems
• Cloud scanners
• Payroll services
• Transactional email platforms

SPF validates the envelope-sender domain, which is not always the address users see in the From field. That distinction is one reason SPF alone cannot reliably prevent visible-domain spoofing. The SPF standard allows domain owners to publish which hosts are authorised to use their domain during SMTP delivery. 

The One-SPF-Record Rule

A domain should have one SPF TXT record.

Do not publish separate records such as:

v=spf1 include:spf.protection.outlook.com -all

and:

v=spf1 include:mailvendor.example -all

Multiple SPF records can produce a permanent error.

Combine legitimate sources into one record instead:

v=spf1 include:spf.protection.outlook.com include:mailvendor.example -all

Before adding a service, confirm that it genuinely sends mail using your domain. Adding unnecessary sources expands the number of systems authorised to represent you.

Watch the SPF DNS Lookup Limit

SPF evaluation allows a limited number of DNS-querying mechanisms. Long chains of include, redirect, a, mx and similar mechanisms can exceed that limit.

This frequently happens when businesses keep adding platforms without removing old ones.

Symptoms may include:

• permerror results
• Intermittent delivery problems
• Messages passing at some recipients and failing at others
• An SPF record that looks valid but cannot be fully evaluated

Review every include and remove services that no longer send mail.

Third-party SPF-flattening services exist, but Microsoft advises evaluating them carefully because vendor IP addresses can change and the resulting record must remain accurate. 

What Is DKIM?

DomainKeys Identified Mail, or DKIM, adds a cryptographic signature to outgoing email.

The sending system signs selected parts of the message using a private key. The receiving server retrieves the related public key from DNS and verifies that the message has not been altered in a way that invalidates the signature.

A DKIM signature contains a signing domain, shown in the d= value, and a selector identifying the DNS key.

A DNS record may appear under a name such as:

selector1._domainkey.example.com

DKIM is particularly valuable because the signature can remain valid when SPF fails during forwarding.

However, systems that rewrite message bodies, footers or headers can break DKIM verification. Microsoft notes that some mail systems and security gateways modify messages in transit, which can affect the DKIM result. 

Enable DKIM for Every Sending Domain

Do not configure DKIM only for the primary company domain.

Also review:

• Marketing subdomains
• Billing domains
• Support domains
• Regional domains
• Brand domains
• Transactional email subdomains
• Domains used by acquired businesses

Every domain appearing in an outgoing From address should have an intentional authentication design.

For Microsoft 365 custom domains, publish the required selector records and enable DKIM signing in the relevant Microsoft administration interface.

Third-party platforms should ideally sign using your own domain or an aligned subdomain rather than only the vendor’s domain.

What Is DMARC?

Domain-based Message Authentication, Reporting and Conformance—DMARC—builds on SPF and DKIM.

It asks two main questions:

1. Did SPF or DKIM pass?
2. Does the passing domain align with the domain visible in the message’s From address?

A message passes DMARC when at least one aligned authentication method passes:

Aligned SPF pass

OR

Aligned DKIM pass

DMARC also allows the domain owner to publish a requested handling policy for messages that fail.

The current DMARC specification is RFC 9989, published in May 2026, which replaced RFC 7489. 

What Is DMARC Alignment?

Alignment connects authentication to the address the recipient actually sees.

SPF Alignment

The domain authenticated by SPF must align with the visible From domain.

DKIM Alignment

The domain in the DKIM d= signature must align with the visible From domain.

Consider this message:

From: invoices@example.com

Return-Path: bounce@mailer-vendor.example

DKIM d=mailer-vendor.example

SPF and DKIM may both pass for mailer-vendor.example, but DMARC can still fail because neither authenticated domain aligns with example.com.

Microsoft gives this exact type of failure as a common problem with marketing automation platforms. 

Relaxed and Strict Alignment

DMARC supports relaxed and strict alignment.

Relaxed Alignment

Related subdomains can align with the organisational domain.

For example:

mail.example.com

can align with:

example.com

Strict Alignment

The domains must match exactly.

Strict alignment can be useful in specialised environments, but relaxed alignment is generally easier to operate across legitimate subdomains.

Avoid enabling strict alignment merely because it sounds more secure. Test whether every genuine sending platform can support it first.

The Three DMARC Policies

A DMARC record is published as a DNS TXT record at:

_dmarc.example.com

The main policies are:

p=none

Monitor failures without asking receivers to quarantine or reject them.

v=DMARC1; p=none; rua=mailto:dmarc@example.com

p=quarantine

Ask receiving systems to treat failing messages as suspicious, often by placing them in junk or quarantine.

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com

p=reject

Ask receiving systems to reject messages that fail DMARC.

v=DMARC1; p=reject; rua=mailto:dmarc@example.com

The long-term objective should normally be enforcement, but only after legitimate senders pass consistently. Microsoft recommends a gradual path from none to quarantine and ultimately to reject. 

Why

p=none

Is Not Enforcement

A p=none record provides visibility but does not ask receiving systems to block impersonated messages.

It can help identify:

• Genuine sending services
• Unknown infrastructure
• Alignment failures
• Old platforms
• Spoofing attempts
• Mail volume by source

However, a domain that remains permanently on p=none is monitoring abuse rather than actively preventing it.

Set a target for progressing towards enforcement instead of treating publication of the record as project completion.

Step 1: Inventory Every Legitimate Mail Source

Before changing DMARC policy, create a complete sender inventory.

Ask every department whether it uses a system that sends email using the company’s domains.

Typical sources include:

• Microsoft 365
• Website hosting
• CRM systems
• Marketing platforms
• Ticketing systems
• Accounting software
• Payroll applications
• Recruitment systems
• Backup alerts
• Monitoring platforms
• Printers and scanners
• E-signature services
• Survey platforms
• Customer portals
• Cloud applications

For each source, record:

The most common cause of disruption is an unrecorded legitimate sender.

Step 2: Correct the SPF Record

Build an SPF record that includes every legitimate source that genuinely needs SPF authorisation.

Then:

• Remove obsolete services.
• Confirm that each include is still documented by the provider.
• Check the DNS lookup count.
• Avoid unnecessary a and mx mechanisms.
• Use -all once the sender list is complete.
• Publish separate records for sending subdomains where appropriate.

Do not authorise an entire hosting network when only one dedicated sending service is required.

Also remember that SPF usually breaks when email is forwarded because the forwarding server is not listed in the original sender’s SPF record. This is why DKIM is critical.

Step 3: Configure DKIM Wherever Possible

DKIM should be the preferred alignment method for most third-party senders.

Ask each provider whether it supports:

• Custom DKIM signing
• Your own signing domain
• Custom selectors
• Key rotation
• 2048-bit keys where supported
• Separate configuration for subdomains

A marketing service should ideally sign with:

d=marketing.example.com

when sending from:

news@marketing.example.com

This provides DKIM alignment even when the service uses its own return-path domain.

Microsoft recommends configuring a third-party service to DKIM-sign with your domain as the preferred fix for marketing-platform alignment failures. 

Step 4: Publish DMARC in Monitoring Mode

Begin with a record such as:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

The rua address receives aggregate reports from participating mail receivers.

These reports show:

• Sending IP addresses
• Message volumes
• SPF results
• DKIM results
• Alignment results
• DMARC dispositions

Raw XML reports are difficult to interpret manually. Many organisations use a reporting service to group sources and highlight failures.

Ensure the reporting mailbox or service can handle the expected volume.

Step 5: Analyse Reports Over a Full Business Cycle

Do not move to enforcement after observing only a few days of traffic.

Your reporting window should cover:

• Month-end invoices
• Payroll
• Marketing campaigns
• Scheduled reports
• Annual or quarterly systems
• Customer notifications
• Low-frequency emergency alerts

A sender that operates once each month may not appear during a one-week test.

The required monitoring period varies, but the objective is to observe every legitimate business process.

Step 6: Separate Legitimate Failures From Abuse

For each failing source, determine whether it is:

• A genuine but misconfigured sender
• A forwarding service
• A mailing list
• An abandoned platform
• An unauthorised internal system
• A spoofing attempt
• A typo or unrelated domain

Do not add every failing IP address to SPF.

First identify the service and verify its ownership.

A malicious sender will also appear in reports. Authorising it would defeat the purpose of the project.

Step 7: Fix Alignment, Not Just Authentication

A service may show:

SPF: pass

DKIM: pass

DMARC: fail

This is not contradictory.

It means SPF and DKIM passed for domains that did not align with the visible From address.

Possible fixes include:

• Configure custom DKIM signing.
• Configure a custom return-path domain.
• Use a dedicated aligned subdomain.
• Change the visible From domain.
• Route the mail through an approved relay.
• Replace a platform that cannot support secure alignment.

Adding a vendor to SPF may not solve DMARC when the vendor uses its own envelope domain.

Step 8: Test With a Limited Percentage

DMARC supports the pct tag, which can request enforcement for only a percentage of failing mail.

For example:

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@example.com

This requests quarantine treatment for ten percent of messages that fail.

You can then increase gradually:

pct=25

pct=50

pct=75

pct=100

Not every receiver applies percentage sampling identically, so this should not replace proper sender testing. It can still reduce risk during a staged rollout.

Step 9: Move to

p=quarantine

After reports show that legitimate traffic is consistently aligned, move to quarantine.

Example:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com

Then increase coverage while monitoring:

• Delivery complaints
• Bounce messages
• Vendor alerts
• DMARC reports
• Marketing campaign results
• Customer support issues
• Internal ticket volumes

If a legitimate sender fails, fix its configuration rather than immediately returning the whole domain to p=none.

Step 10: Reach

p=reject

Once legitimate senders authenticate and align correctly, publish:

v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-reports@example.com

Microsoft identifies p=reject as the ultimate objective for active custom domains, provided testing has been completed to avoid rejecting valid messages. 

Continue monitoring after enforcement because new platforms and configuration changes can introduce fresh failures.

Do Not Forget Subdomains

Your main domain may have strong enforcement while an unused subdomain remains available for spoofing.

Use the sp tag to define how subdomains should be treated:

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@example.com

Alternatively, publish separate DMARC records for subdomains that have different requirements.

A dedicated marketing subdomain might use:

marketing.example.com

with its own SPF, DKIM and DMARC configuration.

This isolates reputation and reduces the risk of a marketing-platform mistake affecting ordinary corporate mail.

Protect Domains That Do Not Send Email

Domains and subdomains that never send email should still publish restrictive authentication records.

A non-sending domain may use an SPF record such as:

v=spf1 -all

and DMARC enforcement:

v=DMARC1; p=reject

This makes the intended behaviour clear: no source is authorised to send.

Also review parked domains, alternative spellings and acquired brand domains.

Attackers do not care whether a domain is actively used; they care whether recipients will recognise it.

Forwarding and Mailing Lists

Forwarding creates complications because SPF commonly fails after the message is resent by another server.

DKIM may survive if the message is not modified.

Mailing lists can cause additional problems by:

• Adding subject prefixes
• Changing message bodies
• Adding footers
• Rewriting sender information

The current DMARC standard acknowledges that p=reject can create interoperability problems with some indirect email flows, including mailing lists and forwarding services. 

This does not mean enforcement should be abandoned. It means these flows must be tested and supported through measures such as:

• Preserving DKIM
• Sender rewriting
• Authenticated Received Chain, or ARC
• Proper mailing-list behaviour
• An aligned subdomain
• Alternative collaboration methods

Email Security Gateways Can Break DKIM

A gateway placed between the internet and Microsoft 365 may modify messages by:

• Adding banners
• Rewriting links
• Changing MIME structure
• Adding disclaimers
• Re-encoding content

These changes can invalidate the original DKIM signature.

Microsoft recommends using ARC where supported, Enhanced Filtering for Connectors in suitable Microsoft 365 designs or configuring the gateway to preserve or re-sign DKIM. 

Test inbound and outbound paths separately.

Common Third-Party Sender Problems

Marketing Platforms

The platform signs with its own domain rather than yours.

Fix: Configure custom DKIM and, where available, a custom bounce domain.

Website Contact Forms

The website sends a message claiming to be from the visitor’s external address.

Fix: Send from an address on your own authenticated domain and place the visitor’s address in Reply-To.

Printers and Scanners

The device sends directly to recipients from an unauthorised IP address.

Fix: Relay through Microsoft 365 or another controlled, authenticated service.

CRM and Accounting Systems

The service was added to SPF but does not use an aligned envelope domain.

Fix: Configure custom DKIM or an aligned return path.

Legacy On-Premises Servers

The server sends from a public IP that has changed or is missing from SPF.

Fix: Route through an approved connector or update the architecture.

Common DMARC Mistakes

Going Straight to

p=reject

This can block legitimate systems that nobody included in the inventory.

Staying at

p=none

Forever

Monitoring without a route to enforcement provides limited protection.

Assuming SPF Pass Means DMARC Pass

SPF must also align with the visible sender domain.

Ignoring DKIM

Forwarding often breaks SPF, making DKIM vital.

Publishing Multiple SPF Records

This can cause SPF permanent errors.

Adding Every Vendor to SPF

Some vendors should authenticate through DKIM instead, and unnecessary includes increase risk and complexity.

Ignoring Subdomains

Attackers may spoof a weak or unprotected subdomain.

Forgetting Non-Sending Domains

Unused domains can still be impersonated.

Not Monitoring After Enforcement

New systems may be added later without authentication.

Making DNS Changes Without Ownership

Nobody knows who approved the sender or why it remains authorised.

A Safe Enforcement Roadmap

Phase 1: Discovery

• Inventory all domains.
• Inventory all sending systems.
• Confirm owners.
• Publish monitoring records.
• Collect aggregate reports.

Phase 2: Remediation

• Correct SPF.
• Enable DKIM.
• Configure alignment.
• Remove obsolete senders.
• Separate marketing and transactional traffic.
• Test forwarding and gateways.

Phase 3: Partial Enforcement

• Move low-risk subdomains first.
• Apply p=quarantine.
• Use staged percentages if helpful.
• Monitor support and delivery reports.

Phase 4: Full Enforcement

• Increase to pct=100.
• Move to p=reject.
• Apply an appropriate subdomain policy.
• Protect non-sending domains.
• Continue reporting and reviews.

Email Authentication Checklist

SPF

• One SPF record per domain
• All legitimate sources included
• Obsolete sources removed
• DNS lookup count checked
• -all used when ready
• Non-sending domains protected

DKIM

• Enabled for every active sending domain
• Custom-domain signing enabled for vendors
• Selectors documented
• Keys rotated appropriately
• Gateways tested for modification
• Alignment confirmed

DMARC

• Aggregate reporting configured
• Reports reviewed
• Legitimate senders identified
• Alignment failures corrected
• Policy progressed beyond none
• Subdomain handling configured
• Full enforcement monitored

Final Thoughts

SPF, DKIM and DMARC are most effective when they are treated as an operational programme rather than a one-time DNS task.

SPF identifies authorised sending infrastructure. DKIM proves that a message was signed by a domain and has not been improperly modified. DMARC connects those results to the sender address recipients see and publishes a policy for failures.

The safest route to enforcement is gradual:

1. Discover every legitimate sender.
2. Correct SPF and DKIM.
3. Monitor DMARC reports.
4. Fix alignment problems.
5. Introduce quarantine carefully.
6. Move to rejection when valid mail is consistently passing.
7. Keep monitoring after enforcement.

Do not delay enforcement indefinitely because one old application is difficult to configure. Isolate it, modernise it or replace it.

A properly enforced DMARC policy significantly reduces direct spoofing of your domains, but it does not prevent compromised genuine accounts, lookalike domains or every form of phishing. It should sit alongside strong account security, impersonation protection and user awareness.

The goal is not merely to publish three DNS records.

It is to make sure legitimate email continues to arrive while fraudulent mail claiming to be from your domains becomes far harder to deliver.

Need Help Reaching DMARC Enforcement Safely?

Hamilton Group can help you secure your business domains without disrupting legitimate email.

Our experts can help you:

• Audit every email-sending service
• Correct SPF records
• Configure DKIM for Microsoft 365 and third-party platforms
• Analyse DMARC reports
• Resolve alignment problems
• Secure marketing and transactional subdomains
• Test mail gateways and forwarding
• Protect non-sending domains
• Move safely from p=none to p=reject
• Monitor authentication after enforcement

Visit hgmssp.com, call Hamilton Group on 0330 043 0069, or book a meeting with one of our experts to improve your Microsoft 365 email authentication.