Email is still the most effective attack vector
Over 300 billion emails are sent every day worldwide. Of all recorded cyberattacks, 91% begin with a phishing email. The reason is straightforward: the SMTP protocol, designed in 1982, includes no sender authentication mechanism. Any server can send an email claiming to be from your-domain.com.
If your domain does not have SPF, DKIM and DMARC configured, an attacker can send emails on behalf of your company to your clients, suppliers, or employees. They do not need access to your servers. They only need an SMTP server and your domain name.
This is the threat that the email authentication triad solves.
SPF: who can send on your behalf
SPF (Sender Policy Framework) is a DNS TXT record that declares which IP addresses are authorized to send email on behalf of your domain. When a receiving server gets an email that claims to come from your-domain.com, it queries the SPF record in your DNS and checks whether the sending server's IP is authorized.
A typical SPF record looks like this:
v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.5 -all
Breaking it down:
v=spf1-- Protocol version.include:_spf.google.com-- Authorizes Google Workspace servers.include:sendgrid.net-- Authorizes SendGrid servers for transactional email.ip4:203.0.113.5-- Authorizes a specific IP address.-all-- Reject everything that does not match (hard fail).
The difference between -all and ~all is critical. With -all (hard fail), receiving servers reject unauthorized emails outright. With ~all (soft fail), they mark them as suspicious but still deliver them. In production, you should always use -all.
Common mistake: SPF has a limit of 10 DNS lookups. Each include counts as a lookup, and nested includes count as well. If you exceed 10, the entire SPF record becomes invalid. Tools like dmarcian or mxtoolbox let you verify how many lookups your record consumes.
DKIM: the cryptographic signature of the message
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to the headers of every outgoing email. The sending server signs the message with a private key, and the receiver verifies the signature by querying the public key published as a DNS TXT record.
The public key DNS record is located at a specific subdomain:
selector1._domainkey.your-domain.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
When the receiving server gets a DKIM-signed email:
- It extracts the selector and domain from the
DKIM-Signatureheader. - It queries the public key from DNS.
- It verifies that the signature matches the message content.
If someone modifies the body or headers of the email in transit, the signature becomes invalid. DKIM guarantees integrity: the message that arrives is exactly the one that was sent.
Common mistake: Not rotating DKIM keys periodically. If a private key is compromised and you do not rotate it, the attacker can sign emails on your behalf indefinitely. The recommendation is to rotate keys at least every 6-12 months and use a minimum key length of 2048 bits.
DMARC: the policy that ties it all together
DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy layer. It does not authenticate on its own. Instead, it tells receiving servers what to do when SPF or DKIM fail, and it requires alignment: the domain in the From header must match the domain validated by SPF or DKIM.
A DMARC record is published as a TXT record at _dmarc.your-domain.com:
_dmarc.your-domain.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@your-domain.com; pct=100"
The three possible policies are:
| Policy | Behavior |
|---|---|
| p=none | Monitor only. Emails are delivered even if checks fail. |
| p=quarantine | Failing emails are sent to spam or quarantine. |
| p=reject | Failing emails are rejected outright. They never reach the recipient. |
The rua parameter specifies the address where you will receive DMARC aggregate reports. These reports are XML files that show which servers are sending email on behalf of your domain, which ones pass verification, and which ones fail.
Common mistake: Configuring p=none and never progressing toward reject. The none mode is for initial observation, not for permanent production use. A domain with p=none is not protected against impersonation.
How they work together
The complete verification flow when an email reaches the receiving server is:
- SPF check -- The receiver queries the SPF record of the envelope sender's domain (
MAIL FROM) and checks whether the sending server's IP is authorized. - DKIM check -- The receiver locates the DKIM signature in the headers, retrieves the public key from DNS, and verifies the signature.
- DMARC evaluation -- The receiver checks whether at least one of the two (SPF or DKIM) has passed with alignment to the
Fromdomain. It then applies the defined policy.
None of the three protocols is sufficient on its own:
- SPF alone does not protect against forwarding attacks, because the IP address changes when an email is forwarded.
- DKIM alone does not prevent an attacker from sending email from an unauthorized IP if they do not sign with DKIM.
- DMARC alone cannot exist without SPF or DKIM, because it needs at least one of them to evaluate alignment.
Together, the three form a robust system where SPF validates the server, DKIM validates the message, and DMARC defines the policy and alignment requirements.
The DMARC deployment roadmap
Jumping straight to p=reject without preparation can cause legitimate emails to be rejected. Deployment should be gradual:
Week 1: Deploy in monitoring mode
_dmarc.your-domain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@your-domain.com"
Enable SPF and DKIM for all services that send email on your behalf. Publish DMARC with p=none and rua to start receiving reports.
Weeks 2-4: Analyze reports
Review the aggregate reports. Identify every legitimate service that sends email on your behalf (CRM, marketing, transactional, support tickets). Add their IPs or includes to your SPF record and configure DKIM for each one.
Month 2: Quarantine
_dmarc.your-domain.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@your-domain.com; pct=100"
Emails that fail checks will be sent to spam. Monitor reports for false positives.
Month 3: Full reject
_dmarc.your-domain.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@your-domain.com; pct=100"
Only when there are no false positives, enable full rejection. Your domain is now protected against email impersonation.
DNSSEC: the foundation that protects everything above
SPF, DKIM and DMARC all depend on DNS queries. If an attacker can forge DNS responses (DNS poisoning or DNS spoofing), they can bypass all three protocols. DNSSEC (DNS Security Extensions) cryptographically signs DNS responses, ensuring that the TXT records containing SPF, DKIM and DMARC have not been tampered with.
Without DNSSEC, an attacker with the ability to intercept DNS traffic could return a forged SPF record that authorizes their own IPs, or a DKIM record with a public key they control. DNSSEC closes this vector.
What UareSafe checks
UareSafe evaluates email authentication as part of the DNS dimension of its web security certification. The specific controls include:
- SPF: Record existence, use of
-all, number of lookups within the limit. - DKIM: Existence of DKIM records, adequate key length.
- DMARC: Record existence, policy level (
none/quarantine/reject),ruaconfiguration. - MX: Correct configuration of the domain's MX records.
- DNSSEC: Validation of the DNSSEC chain of trust.
A domain without DMARC set to reject loses significant points in the certification. Correct configuration of all five controls demonstrates that the organization actively protects its email identity.
Email authentication is not optional in 2026
Since February 2024, Google and Yahoo require DMARC for bulk email senders (more than 5,000 messages per day). Microsoft has followed the same path. Domains without email authentication suffer deliverability problems, in addition to the risk of impersonation.
Configuring SPF, DKIM and DMARC correctly protects three things:
- Your brand: No one can send fraudulent emails using your domain.
- Your clients: They will not receive phishing that appears to come from you.
- Your deliverability: Email providers trust domains with DMARC set to
rejectsignificantly more.
The email authentication triad is one of the security measures with the best cost-benefit ratio you can implement. It requires no additional software, has no licensing cost, and is configured directly in your DNS. The only requirement is doing it right.