Sending email on behalf of your domain

The email protocol was designed in a time when the connected parties trusted one another. Filling in a sender address is therefore no harder than writing a name on an envelope: nothing is verified unless you arrange it yourself. Three DNS records arrange it. The order in which you introduce them matters, and a half-filled configuration achieves little.

What is email spoofing?

Email spoofing is sending email with a forged sender address. An attacker sending mail with billing@yourcompany.com as the sender needs no access to your systems; they simply fill in that value when sending.

Whether that works depends entirely on what your DNS says about your domain. Three records together give the answer. SPF lists which servers may send on behalf of your domain. DKIM adds a digital signature to outgoing mail, so the recipient can verify the message comes from you and was not altered in transit. DMARC connects those two to the address the recipient actually sees, and states what should happen when the check fails.

Without those records the receiving server faces an impossible question. It sees mail claiming to be from you and has no way to test that. In doubt it delivers, because refusing mail that is genuine is the bigger problem from its point of view.

How do you configure SPF, DKIM and DMARC?

Vulnerable:

yourcompany.com.    TXT    "v=spf1 include:_spf.provider.com ~all"

This looks tidy and is still insufficient. The tilde in ~all means softfail: the recipient may accept and at most mark the mail, and in practice it simply arrives. More important is what is missing. There is no DKIM signature and no DMARC record, so nobody knows what should happen when a check fails.

And there is a subtlety that makes the SPF check largely bypassable: SPF looks at the envelope address, not the address the recipient sees in their inbox. An attacker can use an envelope address on their own domain, which makes SPF pass neatly, while putting your address in the visible From field. Without DMARC that difference is checked nowhere.

Safe:

; Which servers may send; hardfail for the rest
yourcompany.com.             TXT  "v=spf1 include:_spf.provider.com -all"

; Public key for the signature
sel1._domainkey.yourcompany.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

; Ties both to the visible sender address
_dmarc.yourcompany.com.      TXT  "v=DMARC1; p=reject; adkim=s; aspf=s;
                                    rua=mailto:dmarc@yourcompany.com; pct=100"

Now the whole thing closes. -all instructs recipients to refuse mail from other servers. The DKIM signature makes tampering in transit visible. And DMARC with p=reject says what should happen when it goes wrong, while adkim=s and aspf=s enforce that the checked domain matches the visible sender address exactly, which is precisely the gap SPF alone leaves open. The rua address gives you periodic summaries of who is sending on your behalf.

The order of introduction is decisive. Start with p=none and reporting, gather data for a few weeks, identify all legitimate sending parties, newsletters, invoicing systems, recruitment platforms, your accounting package, and only then tighten through quarantine to reject.

What is the impact of email spoofing?

The severity is rated medium to high, with the context of your organisation weighing heavily. The vulnerability sits not in your application but in the trust attached to your name.

The most common abuse is phishing aimed at your own customers. An email that genuinely appears to come from your domain, with your house style and a plausible pretext, achieves considerably higher response rates than a message from an unfamiliar address. The damage falls on your customers, but the reputational damage lands with you.

Then there is the internal variant, which in practice costs the most. A message appearing to come from the board or the finance department, asking for an urgent payment or a change of bank details, is the core of what is called CEO fraud. Staff are trained to watch for unusual sender addresses, but here the address is correct.

There is an indirect consequence too. If your domain is abused at scale to send unwanted mail, its reputation with receiving parties can drop, which worsens delivery of your own legitimate email.

How do you detect email spoofing?

The check starts with retrieving the DNS records for the domain. Is there an SPF record, and does it end in -all or the more lenient ~all? Is there a DMARC record, and is the policy none, quarantine or reject? Is a DKIM selector in use, and what key length does it have?

Then the practical test: a message is sent with the domain as sender from a server not listed in the records, to see whether it is delivered. Subdomains get attention as well, because they do not automatically fall under the policy of the main domain unless that is arranged explicitly. Parked and unused domains are examined too, because those often have no records at all and are attractive for exactly that reason. Finally the number of DNS lookups in the SPF record is counted, because exceeding it silently invalidates the record. AssistSec includes this check when mapping your external attack surface, because a well-secured application helps little against an attack arriving under your organisation’s name.

How do you prevent email spoofing?

• Publish an SPF record naming all legitimate sending parties and ending in -all.
• Sign outgoing mail with DKIM and use a key of at least 2048 bits.
• Publish a DMARC record and work towards p=reject with strict alignment.
• Start with p=none and reporting to map all sending sources before you tighten.
• Read the DMARC reports and act on them; without follow-up the record is a formality.
• Arrange the policy for subdomains too, explicitly through sp=.
• Give parked and unused domains an SPF record permitting nothing and DMARC on reject.
• Keep the number of DNS lookups in your SPF record below ten.
• Review the records when you start using a new service that sends email on your behalf.