Protecting Your Domain from Email Spoofing

Table of Contents

• Why spoofing matters
• How authentication stops spoofing
• Setting up protection
• Protecting domains that do not send email
• If your domain is being spoofed
• Have more questions?

Email spoofing is when someone sends email that appears to come from your domain without your authorization. It is possible because the SMTP protocol does not verify sender identity by default - any mail server can claim to be sending on behalf of any domain. DNS-based authentication protocols close this gap.

Why spoofing matters

Spoofed emails cause problems for the domain owner, not just the recipients:

• Phishing - Attackers impersonate your domain to trick recipients into revealing credentials or clicking malicious links. Your customers or partners may be targeted.
• Reputation damage - Mailbox providers track spam complaints and authentication failures against your domain. Spoofed messages you did not send still count against you.
• Blacklisting - Sustained spoofing can get your domain or associated IPs placed on blacklists, affecting the deliverability of your legitimate email.
• Loss of trust - Recipients who receive spoofed email from your domain may stop trusting your real messages.

Even domains that do not send email should be protected. Attackers specifically target domains without authentication records because nothing blocks their spoofed messages.

How authentication stops spoofing

Three DNS-based protocols work together to let receiving mail servers verify that an email genuinely came from your domain:

SPF: who is allowed to send

An SPF record is a TXT record that lists every server and service authorized to send email for your domain. When a receiving server gets a message claiming to be from yourdomain.com, it checks the sending IP against this list. If the IP is not authorized, SPF fails.

SPF alone does not stop spoofing. Attackers can pass SPF by sending from their own domain while displaying your domain in the “From” header (which SPF does not check). That is where DKIM and DMARC come in.

DKIM: proving the message is authentic

A DKIM record publishes a public key as a TXT record. Your email provider signs every outgoing message with the corresponding private key. The receiving server retrieves the public key from DNS and verifies the signature. If the message was altered in transit, or if the sender does not have the private key, DKIM fails.

DKIM is harder to forge than SPF because the attacker would need your private key to produce a valid signature.

DMARC: enforcing the rules

A DMARC record ties SPF and DKIM together with a policy. It tells receiving servers:

• What to do when neither SPF nor DKIM passes with alignment - p=none (do nothing), p=quarantine (send to spam), or p=reject (block entirely).
• Where to send reports - Aggregate reports (rua=) show you who is sending email using your domain and whether messages pass or fail authentication.

A p=reject policy is the strongest protection against spoofing. It tells receiving servers to refuse any message that fails both SPF and DKIM alignment.

Setting up protection

Configuring all three protocols requires adding TXT records in DNS. DNSimple’s Record Editor handles all of them. The dedicated setup guides walk through each one:

1. SPF - Set Up SPF Records covers listing all authorized senders and staying under the 10-lookup limit.
2. DKIM - Set Up DKIM covers adding the public key for each email service. If you use multiple services, see Managing Multiple DKIM Selectors.
3. DMARC - Set Up DMARC covers publishing a policy and setting up reporting. Start with p=none and tighten gradually - see Implementing a Gradual DMARC Policy.

Protecting domains that do not send email

If you own a domain that should never send email, publish records that explicitly say so. This prevents attackers from spoofing it:

• SPF: v=spf1 -all (no servers are authorized)
• DMARC: v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com (reject everything, send reports)
• Null MX: A null MX record signals that the domain does not accept inbound email either.

If your domain is being spoofed

If you discover someone is sending spoofed email using your domain:

1. Check your DMARC reports. Look for source IPs you do not recognize. If you do not have DMARC reporting set up, add a rua= tag to your DMARC record now.
2. Verify your authentication records are correct. Confirm SPF includes all legitimate senders, DKIM is configured for each service, and DMARC alignment is working. See Verify SPF, Verify DKIM, and Verify DMARC.
3. Tighten your DMARC policy. If you are still on p=none or p=quarantine, move toward p=reject to block spoofed messages at the receiving server.
4. Check blacklists. Spoofing campaigns can get your domain listed. Use MXToolbox to check and follow the delisting process if needed.
5. Monitor closely for the following weeks. Spoofing campaigns often come in waves.

Have more questions?

If you have additional questions or need assistance with protecting your domain from email spoofing, contact support, and we’ll be happy to help.