Email authentication sounds more complicated than it needs to be. The basic idea is simple: when an email claims to come from your business, the receiving mail system needs a way to check whether that message was sent by a system your business actually uses.
SPF, DKIM and DMARC are the three main pieces used to do that. They work together. Having one DNS record somewhere does not automatically mean the domain is properly protected.
Why email authentication matters
Without email authentication, it is easier for somebody to send a message that appears to come from your domain even though it was sent from somewhere else. That can be useful for phishing, fake invoice requests and other forms of impersonation.
Email authentication gives receiving systems more information to decide whether a message is genuine. It can also improve the consistency of legitimate email delivery because the systems receiving your mail can see that the sending infrastructure has been authorised properly.
Photo by NordWood Themes via Unsplash.
What does SPF do?
SPF tells receiving mail systems which servers or services are allowed to send email for a domain. The information is published as a DNS record.
The catch is that SPF does not simply look at the address a person sees in the From field. It checks the technical sending domain used during mail delivery. That means SPF on its own is not enough to stop somebody displaying your domain in the visible From address.
SPF also needs to reflect the services the business genuinely uses. Microsoft 365 might be one source, while a CRM, accounting platform, website, newsletter service or line-of-business application may send mail as well. If those services are not accounted for, legitimate messages can fail authentication.
What does DKIM do?
DKIM adds a cryptographic signature to outgoing email. The receiving system can use the public key published in DNS to confirm that the message was signed by the sending domain and that important parts of the message were not altered after it was signed.
For Microsoft 365 and most other modern business email platforms, DKIM should be configured for the organisation’s own domain rather than relying only on the provider’s default signing domain.
What does DMARC do?
DMARC ties the other checks back to the domain people actually see in the From address. A message can pass DMARC when SPF or DKIM passes and the authenticated domain aligns with the visible From domain.
DMARC also lets the domain owner publish a policy telling receiving systems what to do when authentication fails. Depending on the stage of the rollout, that might be monitoring only, asking receivers to quarantine suspicious mail, or asking them to reject it.
The reporting side is just as useful. DMARC reports can show unexpected systems trying to send as your domain, but they can also expose legitimate services somebody forgot about.
Do SPF, DKIM and DMARC need to be used together?
Yes, that is the sensible approach. SPF identifies authorised sending infrastructure, DKIM signs legitimate mail, and DMARC checks whether those authentication results line up with the domain the recipient sees.
Microsoft’s current guidance is that SPF, DKIM and DMARC should work together for effective email authentication. Google also recommends configuring all three rather than stopping after SPF.
Photo by Jonathan Francisca via Unsplash.
The common mistake is turning on DMARC too aggressively
A strict DMARC policy can be very useful, but publishing a reject policy before you understand every legitimate sender can break genuine business email.
A better rollout is normally to make sure SPF and DKIM are in order first, start collecting DMARC reports, identify the systems sending mail for the domain, fix anything that is not aligned properly, and then increase enforcement once the results are clean.
This is one of those areas where the DNS record itself is the easy part. The useful work is understanding every service that sends email for the business and making sure the authentication settings still make sense when those services change.
Email authentication does not stop every phishing attack
SPF, DKIM and DMARC make it harder to impersonate your exact domain, but they do not solve every email security problem.
If an attacker compromises a real mailbox, the messages may be sent through legitimate systems and authenticate correctly. An attacker can also register a lookalike domain that appears similar to yours. That is why email authentication still needs to sit alongside MFA, account monitoring, email filtering and sensible verification processes for payments and sensitive requests.
We cover those account-takeover risks in our guide to phishing, MFA fatigue and account takeovers.
What should a business ask its IT provider?
You do not need to become a DNS expert. The useful questions are whether SPF covers every legitimate sender, whether DKIM is enabled for the business domain, whether DMARC is collecting reports, what the current DMARC policy is, and whether somebody reviews the setup when a new system starts sending email.
If the answer is simply “we have an SPF record”, that is not the whole job.
Keep it maintained, not just configured once
Email environments change. Marketing platforms get replaced, websites move, accounting systems start sending notifications and old services are forgotten. Email authentication should be checked when those changes happen rather than treated as a one-off DNS task.
Q10 can review email authentication as part of a wider cybersecurity or Microsoft 365 review, clean up SPF, DKIM and DMARC where needed, and help work out which systems should actually be authorised to send as the business.