Most marketing teams have heard of SPF, DKIM and DMARC. Fewer know what they actually do, how they work together, or what happens when they are not set up correctly.
That matters, because misconfigured authentication is one of the most common causes of deliverability problems. Emails that should reach the inbox end up in spam. Domain reputation is damaged. And because the issue is invisible to most senders, it can go unnoticed for months.
This post explains what each protocol does, why they need to work together, and what the consequences are when they do not. For deeper reasons why your emails may be going to spam outside just authentication you can read our other blog article on Reasons My Emails Are Going to Spam
What these protocols are actually for
SPF, DKIM and DMARC are email authentication standards. Their job is to prove to inbox providers that an email claiming to be from your domain was genuinely sent by you, and not by someone spoofing your address.
Without authentication, anyone can send an email that appears to come from your domain. Inbox providers know this, and they treat unauthenticated email with suspicion. Even if your list is clean and your content is good, failing authentication checks will work against you.
SPF: who is allowed to send on your behalf
SPF stands for Sender Policy Framework. It is a DNS record that lists the servers and services authorised to send email from your domain.
When an inbox provider receives an email from your domain, it checks your SPF record to see whether the sending server is on the approved list. If it is, SPF passes. If it is not, the email is treated as suspicious.
The most common SPF problems are not about the record being absent entirely. They are about it being out of date. If you have added a new email platform, a CRM with email functionality, or a transactional email tool and not updated your SPF record to include it, emails from that tool may fail SPF. That is a very common situation, and it often goes unnoticed until deliverability starts to slip.
There is also a technical limit worth knowing about. SPF records can only trigger ten DNS lookups before they become invalid. Organisations that have accumulated multiple sending tools over time often hit this without realising it, and the result is SPF failures that are hard to trace back to the cause.
DKIM: proving the email has not been tampered with
DKIM stands for DomainKeys Identified Mail. It works differently from SPF. Rather than checking whether the sending server is authorised, it checks whether the email itself has been altered in transit.
When you send an email, your server adds a digital signature to the message headers. The inbox provider retrieves a public key from your DNS records and uses it to verify that signature. If the email has not been modified since it was sent, DKIM passes. If anything has changed, it fails.
DKIM matters for a specific reason that SPF cannot cover. The signature travels with the email, so it still provides a valid reputation signal even when a message is forwarded. SPF breaks on forwarding because the sending server changes. DKIM does not.
Common DKIM issues include keys that were set up once and never rotated, mismatches between the signing domain and the sending domain, and platforms that send on your behalf using their own DKIM keys rather than yours. That last one is worth paying attention to, because it affects the domain alignment that DMARC depends on.
DMARC: the policy that ties it all together
DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It builds on SPF and DKIM and gives you control over what happens when authentication fails.
A DMARC record tells inbox providers what to do with emails that fail authentication checks. The three policy options are none (monitor only, take no action), quarantine (route to spam), and reject (block entirely).
DMARC also introduces an alignment requirement. It is not enough for SPF or DKIM to pass in isolation. The domain used in those checks needs to match the domain in the From address that the recipient actually sees. This closes a significant loophole. Without alignment, a spammer could pass SPF by using their own authorised server while still spoofing your domain in the From field.
DMARC reporting is one of the more useful things it offers. The reports show you every source sending email from your domain, whether that is a legitimate tool you have authorised or a third party attempting to spoof you. Without DMARC, that activity is largely invisible.
In UK enterprise mail environments, DMARC enforcement is increasingly expected. Senders without a policy at enforcement level are at a disadvantage when it comes to filtering decisions at large receiving organisations.
Starting at a none policy and working toward reject is the right approach. Moving too quickly to a restrictive policy without a clear picture of your sending sources will cause legitimate email to be blocked.
Why getting this wrong is costly
Authentication problems rarely announce themselves. Emails may still be delivered. Open rates may look broadly normal. But inbox providers are watching, and consistent authentication failures erode the reputation signals that determine where your emails land over time.
There is also the spoofing exposure. Without DMARC at enforcement, your domain can be used by third parties to send phishing or spam emails. That activity damages your domain reputation whether you are aware of it or not. The inbox providers receiving those emails have no way to distinguish between you and whoever is spoofing you.
For UK SaaS and e-commerce businesses, where email drives revenue, retention and activation, the cost shows up in reduced reach and lost conversions from emails that never arrived. It is a slow leak rather than a sudden failure, which is part of what makes it so easy to miss.
What correct authentication looks like
SPF, DKIM and DMARC should all be in place, correctly configured, and aligned with each other and with your actual sending infrastructure. Every tool or platform sending email on your domain's behalf needs to be covered, including any third-party platforms handling transactional or marketing email.
DMARC should be progressing toward enforcement, not sitting indefinitely at a none policy. The reporting data at none policy is genuinely useful for mapping your sending landscape, but it provides no protection against spoofing and no enforcement signal to inbox providers.
If you have changed ESP, added new tools, or grown your sending infrastructure over time without a corresponding review of your authentication records, there is a reasonable chance something is out of alignment. That is worth finding out before it starts affecting deliverability.
Getting a clear picture of where you stand
If you are not confident that your authentication is correctly set up across all your sending infrastructure, a deliverability audit will tell you what is in place, what is missing, and what needs to change.
Digistrat works with UK SaaS, app-based and e-commerce businesses on exactly this. If you want to understand whether your authentication is properly configured, a Deliverability Audit is the right place to start.
