Tackling Email Spoofing and Phishing

Why Email Authentication Starts With DNS

Email spoofing remains one of the most effective ways for attackers to reach victims, and the reason is simple: the From header that mail clients display is not verified by default. Anyone with a mail server can send a message with a forged From header claiming to be your company, and unless the receiving server performs additional checks, the message lands in the inbox looking legitimate.

The consequences are measurable. The FBI’s 2020 Internet Crime Report recorded over 240,000 phishing victims with losses exceeding $50 million, and victim counts have more than doubled since 2019. The 2020 Verizon Data Breach Investigations Report puts phishing behind more than 80% of all social engineering attacks, with 96% of those attacks delivered via email.

Addressing the problem requires a set of DNS records that let receiving mail servers authenticate messages. SPF, DKIM, and DMARC work together to verify that an email really comes from your domain — and to tell receiving servers what to do when verification fails. But getting those records right is a DNS chore many domain owners put off, often because the format is confusing and misconfigurations can break legitimate mail delivery.

To lower that barrier, Cloudflare is introducing an Email Security DNS Wizard. The tool automates the creation of the necessary DNS records, scans for existing misconfigurations, and shows recommendations for fixing insecure setups. It begins rolling out to Free plan users today, with Pro, Business, and Enterprise customers following in the coming weeks.

How Spoofed Email Actually Works

Email spoofing is distinct from domain spoofing, where an attacker registers a lookalike domain like mycoolwebpaqe.xyz to impersonate mycoolwebpage.xyz in a browser. Email spoofing requires no lookalike domain at all — the attacker simply alters the From header of a message sent from their own server.

Examining the raw source of a legitimate email reveals the gap. Headers for received time, sender, reply-to, and recipient are all present, but mail clients render the display name and address from the From header alone. A message arriving with From: Cloudflare <[email protected]> looks like it came from Cloudflare, no matter which server actually transmitted it. Without authentication checks at the receiving end, the recipient has no way to distinguish the forgery.

Date: Thu, 23 Sep 2021 10:30:02 -0500 (CDT)
From: Cloudflare <[email protected]>
Reply-To: [email protected]
To: <my_personal_email_address>

From Spoofing to Phishing

Spoofing becomes phishing when forged sender identity is paired with a convincing lure. Attackers replicate corporate branding and styling, then send urgent requests: update account information, verify a payment, reset a password. The embedded link may point to a spoofed web portal that captures credentials, or it may trigger code execution on the victim’s machine. If the receiving mail server does not flag the message as spam or fail an authentication check, the user is left with no warning before clicking.

The volume of these attempts is the real challenge. With phishing representing the overwhelming majority of social engineering incidents, and email being the delivery mechanism for nearly all of them, domain owners need a way to make their domains unattractive spoofing targets in the first place.

The DNS Fix, Automatically

Three DNS record types close the spoofing hole:

• SPF — publishes the list of mail servers authorized to send email for the domain.
• DKIM — provides a public key that receiving servers use to verify a message was signed by the sending domain.
• DMARC — tells receiving servers how to handle messages that fail SPF and DKIM checks, typically by rejecting or quarantining them.

Correctly deployed, these records make it straightforward for receiving mail servers to reject forged mail before it reaches the inbox. Incorrectly deployed, they can cause legitimate email to be bounced — a risk that makes many domain owners hesitant to touch their DNS settings.

The new wizard aims to remove that hesitation by generating the records automatically from information about a domain’s mail setup. It then issues warnings when it detects DNS configurations that leave a domain exposed to spoofing, along with step-by-step recommendations to remediate them. For Cloudflare customers, the fix is applied directly in the same DNS management interface they already use, keeping the whole process in one place.

The rollout starts with Free plan users, and the feature will expand to all plan levels over the following weeks.

Why DNS-level defenses matter against spoofing

Email spoofing and phishing rely on forging the From header so a message appears to come from a trusted domain. The Domain Name System (DNS) already carries three standards that let domain owners declare who may send mail for them, sign messages cryptographically, and tell receivers what to do with messages that fail those checks:

• Sender Policy Framework (SPF)
• DomainKeys Identified Mail (DKIM)
• Domain-based Message Authentication Reporting and Conformance (DMARC)

All three are published as DNS TXT records. Configuring them correctly is the tricky part: a policy that is too strict will drop legitimate mail, while one that is too relaxed leaves the domain open to abuse.

SPF: declaring authorized senders

SPF is a TXT record that lists which IP addresses and domains may send mail on behalf of your domain. The record for cloudflare.com illustrates the structure:

cloudflare.com 	TXT	"v=spf1 ip4:199.15.212.0/22 ip4:173.245.48.0/20 include:_spf.google.com include:spf1.mcsv.net include:spf.mandrillapp.com include:mail.zendesk.com include:stspg-customer.com include:_spf.salesforce.com -all"

An SPF record must begin with v=spf1. It typically contains a list of sending server addresses via the ip4 or ip6 mechanisms. The include mechanism references another domain's SPF record, which is how you authorize third-party providers — such as Zendesk for support or Mandrill for marketing — to send on your behalf.

The record ends with a catch-all all mechanism, prefixed by a qualifier that controls how unmatched mail is treated:

• + (Allow) accepts everything, which makes the SPF record pointless.
• ~ (Softfail) leaves the decision to the receiver, often resulting in spam-folder placement.
• - (Fail) tells receivers to reject mail from any source not listed.

The SPF check works in three steps:

1. An email is sent from IP 203.0.113.10 with a From header of [email protected].
2. The receiver queries the SPF TXT record on mycoolwebpage.xyz.
3. If the sending IP is listed, the check passes. If not, the all qualifier determines the result.

Full details on SPF mechanisms are in RFC7208.

DKIM: cryptographic message signing

SPF alone has a gap: it authorizes an IP, not an identity. If an IP's owner changes, or if another user on a shared mail server attempts to spoof your domain, SPF can't help. DKIM closes that gap with public-key cryptography.

DKIM signs the email body and selected headers with a private key. Receivers verify the signature using a public key published in DNS. Tw The Cloudflare DKIM record looks like this:

google._domainkey.cloudflare.com.	TXT	"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDMxbNxA2V84XMpZgzMgHHey3TQFvHkwlPF2a11Ex6PGD71Sp8elVMMCdZhPYqDlzbehg9aWVwPz0+n3oRD73o+JXoSswgUXPV82O8s8dGny/BAJklo0+y+Bh2Op4YPGhClT6mRO2i5Qiqo4vPCuc6GB34Fyx7yhreDNKY9BNMUtQIDAQAB"

The record lives at <selector>._domainkey.<domain>, where the selector is chosen by the email provider. The content starts with v=DKIM1, followed by the key type (k tag) and the public key itself (p tag).

The signed portion of the message travels in a DKIM-Signature header. A Cloudflare product-update email provides an example:

DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
   t=1632416903; s=m1; d=cloudflare.com; [email protected];
   h=Content-Type:MIME-Version:Subject:To:From:Date;
   bh=uMixy0BsCqhbru4fqPZQdeZY5Pq865sNAnOAxNgUS0s=;
   b=LiIvJeRyqMo0gngiCygwpiKphJjYezb5kXBKCNj8DqRVcCk7obK6OUg4o+EufEbB
    tRYQfQhgIkx5m70IqA6dP+DBZUcsJyS9C+vm2xRK7qyHi2hUFpYS5pkeiNVoQk/Wk4w
    ZG4tu/g+OA49mS7VX+64FXr79MPwOMRRmJ3lNwJU=

That header shows the signing domain (d=cloudflare.com), the selector (s=google), the list of signed headers (h=), and the signature itself (b=). The verification flow is:

1. The sending server canonicalizes the listed headers and message body.
2. It signs the result with the private DKIM key.
3. The signature is included in the outgoing DKIM-Signature header.
4. The receiver fetches the public key from the TXT record on the sending domain.
5. The receiver re-canonicalizes the received message.
6. It verifies the signature against the public key.
7. A valid signature proves the message wasn't altered in transit and originates from a holder of the private key.

DKIM is specified in RFC4871 and RFC5672.

DMARC: policy and reporting

DMARC adds two things SPF and DKIM don't provide: a clear policy for handling failures, and feedback to the domain owner. The DMARC TXT record is always published on the _dmarc subdomain:

_dmarc.cloudflare.com.   TXT   "v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]"

The record for cloudflare.com starts with v=DMARC1 and includes three key tags:

• p — the policy for messages failing SPF or DKIM. none is monitoring only; quarantine sends failures to spam; reject drops them entirely.
• pct — applies the policy to a percentage of messages, useful during rollout.
• rua — the address that receives aggregate reports, typically daily, about non-conforming mail.

With DMARC in place, the flow becomes:

1. A message arrives with From: [email protected].
2. The receiver fetches that domain's SPF, DKIM, and DMARC records.
3. If SPF or DKIM pass, the message is delivered. If both fail, the p tag decides between inbox, spam, or rejection.
4. The receiver sends an aggregate report to the address in rua.

The complete DMARC specification is in RFC7489.

Adoption is still low

Despite the availability of these standards, deployment remains patchy. Data from dmarc.org shows that by the end of 2020 fewer than half of domains had published any DMARC record — and of those that had, more than 65% used the monitoring-only p=none policy.

A 2021 report on the banking sector tells a similar story. Among 2,881 U.S. banking entities, only 44% had published a DMARC record. Of those, roughly two in five used p=none and another 8% were misconfigured. Denmark's banking sector led with 94% adoption, while Japan trailed at 13%. SPF adoption is generally higher, likely because it dates to an experimental RFC in 2006, while DMARC only became a standard in 2015.

The gap leaves substantial room for improvement.

Cloudflare's Email Security DNS Wizard

To simplify deployment, Cloudflare has added an Email Security DNS Wizard to the DNS tab of its dashboard. Users see two new elements there: a dedicated Email Security section and warnings about insecure configurations.

Clicking Configure in the Email Security section opens the wizard with two paths:

• If the domain sends email, the wizard walks through creating SPF, DKIM, and DMARC records step by step.
• If the domain does not send email, a single click creates all three records with strict policies.

For non-sending domains, clicking Submit publishes SPF, DKIM, and DMARC records configured so that any mail claiming to come from the domain fails the checks and is rejected by receiving servers.

example.com			TXT	"v=spf1 -all"
*._domainkey.example.com.	TXT	"v=DKIM1; p="
_dmarc.example.com.		TXT	"v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s;"

Domain owners can start from the DNS tab in the Cloudflare dashboard, or sign up for free. More background on these email-related DNS records is available on Cloudflare's learning pages.