SPF, DKIM and DMARC are the three records that prove an email really came from your domain. Misconfigured or unenforced, they leave your domain open to spoofing and phishing that targets your staff and customers. Validating them from the outside confirms whether an attacker can send mail that looks like you.
Email remains one of the most common ways attackers gain an initial foothold. While phishing campaigns continue to evolve, one tactic has remained remarkably effective: sending emails that appear to come from a trusted domain.
If an attacker can impersonate your organisation’s email address, they immediately gain credibility with employees, customers, suppliers, and partners. That credibility can be used to steal credentials, redirect payments, distribute malware, or damage your brand.
Fortunately, email authentication standards exist to make domain spoofing significantly more difficult. Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting and Conformance (DMARC) work together to prove whether an email genuinely originated from your organisation.
The challenge is that simply publishing these records is not enough. From an attacker’s perspective, the important question is whether they are correctly configured and enforced. External validation answers that question before an attacker does.
What SPF, DKIM and DMARC each do
Sender Policy Framework (SPF)
Sender Policy Framework (SPF) is a Domain Name System (DNS) record that specifies which mail servers are authorised to send email on behalf of your domain.
When a receiving mail server receives a message claiming to come from your organisation, it checks the SPF record to determine whether the sending server is authorised.
If the sending server is not listed, the SPF check fails.
SPF helps prevent unauthorised mail servers from sending messages that appear to originate from your domain, but it has limitations. It does not protect every forwarding scenario, and by itself it does not tell receiving systems how to handle failed messages.
DomainKeys Identified Mail (DKIM)
DomainKeys Identified Mail (DKIM) uses cryptographic signatures to prove that an email has not been modified after it was sent.
When an organisation sends an email, its mail server digitally signs the message using a private key. Receiving systems validate that signature using a public key published in DNS.
If the signature matches, the recipient gains confidence that the message has not been altered during transit.
DKIM protects message integrity, but it does not authorise who is allowed to send email for the domain.
Domain-based Message Authentication, Reporting and Conformance (DMARC)
Domain-based Message Authentication, Reporting and Conformance (DMARC) ties SPF and DKIM together.
It tells receiving mail systems what to do when an email fails authentication and provides reporting that allows domain owners to monitor authentication activity.
A DMARC policy can instruct receiving systems to:
- Monitor authentication failures
- Quarantine suspicious messages
- Reject unauthorised emails entirely
Without DMARC, failed SPF or DKIM checks do not necessarily stop spoofed emails from reaching recipients.
Why email authentication is part of your external attack surface
Most organisations think of their external attack surface as websites, cloud services, APIs, or public infrastructure.
Email belongs in that conversation as well.
Your email domain is publicly visible.
Its DNS records are publicly accessible.
Attackers can inspect your authentication policies without sending a single packet to your internal network.
If SPF, DKIM, or DMARC are missing or weak, attackers immediately know that your domain may be easier to impersonate.
Unlike software vulnerabilities, there is often no need for exploitation.
The opportunity already exists.
From an external security perspective, email authentication is another internet-facing control that should be continuously validated.
The common failure: DMARC published at p=none and never enforced
One of the most common findings during external email security reviews is a DMARC policy published with:
p=noneAt first glance, this appears positive because DMARC has been implemented.
In reality, p=none is a monitoring mode.
It requests authentication reports but tells receiving mail systems to take no action when authentication fails.
That means spoofed emails can still be delivered depending on the recipient’s mail provider and security policies.
Many organisations publish p=none with the intention of moving to enforcement later.
Months or even years pass.
The policy never changes.
The result is an organisation collecting reports while leaving the door open for domain spoofing.
Monitoring is an important first step.
It should not become the final destination.
How attackers abuse a weak or missing DMARC policy
Attackers rarely need to compromise your mail server to impersonate your organisation.
Instead, they attempt to send emails that appear to originate from your domain.
Their objectives may include:
- Phishing employee credentials
- Business Email Compromise (BEC)
- Invoice fraud
- Brand impersonation
- Malware delivery
- Customer scams
If email authentication policies are weak, recipients may receive messages that appear legitimate because the visible sender matches your organisation.
Even if some mail providers perform additional checks, inconsistent enforcement creates opportunities for attackers.
The damage extends beyond compromised accounts.
Customers lose confidence.
Partners question legitimate communications.
Support teams spend time responding to fraudulent emails.
Brand reputation suffers.
Strong email authentication significantly reduces the success of exact-domain spoofing attacks.
Validating email authentication continuously, not once
Publishing SPF, DKIM, and DMARC records is not a one-time project.
Cloud services change.
Marketing platforms are introduced.
Third-party providers send newsletters.
Human resources systems deliver notifications.
Customer relationship management platforms send automated emails.
Each legitimate sender must authenticate correctly.
Without continuous validation, organisations may unknowingly introduce new sending services that fail authentication or weaken existing policies.
External validation confirms questions such as:
- Are SPF records valid?
- Are authorised senders correctly configured?
- Are DKIM signatures working?
- Is DMARC aligned correctly?
- Is enforcement active?
- Have new services introduced authentication failures?
Continuous validation provides confidence that email authentication remains effective as the environment changes.
From check to enforcement: a safe path to p=reject
Moving directly to a strict DMARC policy without preparation can disrupt legitimate business communications.
A staged approach reduces that risk.
Step 1: Publish DMARC with monitoring
Begin with p=none while collecting reports to understand which services legitimately send email on behalf of your domain.
Review authentication failures carefully.
Step 2: Fix legitimate senders
Configure every approved email service so that SPF, DKIM, and DMARC align correctly.
Remove outdated services that no longer require authorisation.
Validate that business-critical mail continues to authenticate successfully.
Step 3: Move to quarantine
Once legitimate senders consistently pass authentication, move to:
p=quarantineThis instructs receiving systems to treat unauthorised messages as suspicious while continuing to monitor reporting.
Step 4: Enforce rejection
When confidence is high that legitimate email authenticates correctly, move to:
p=rejectThis provides the strongest protection against exact-domain spoofing by instructing receiving systems to reject unauthorised messages before they reach recipients.
The transition should always be driven by validated evidence rather than assumptions.
Closing the email spoofing gap
Attackers understand that trust is one of the most valuable assets an organisation has.
Email spoofing exploits that trust without requiring malware, software vulnerabilities, or compromised infrastructure.
SPF, DKIM, and DMARC work together to prove that emails genuinely originate from your domain, but they only provide meaningful protection when correctly configured and enforced.
External validation confirms whether attackers can still impersonate your organisation, identifies gaps before they are abused, and provides confidence that authentication policies continue to operate as intended.
Attack Insights helps organisations continuously validate their email security posture from an external perspective while strengthening broader digital risk protection against brand impersonation, phishing, and other internet-facing threats.
Request a Demo
Your email domain is part of your external attack surface.
Request a demo of Attack Insights to see how our email security capabilities continuously validate SPF, DKIM, and DMARC, confirm whether your domain can still be spoofed, and help your organisation move safely from monitoring to full enforcement.
