Your CMS Sends Email. Is the Domain Allowed To?

Photo by Atlantic Ambience on Pexels

If the domain has not said who may send for it, the receiving server assumes nobody may.

Every Drupal site sends mail. Password resets, account confirmations, contact form submissions, order receipts, comment notifications. It happens in the background, configured once and forgotten, and it works until the day someone says the contact form is broken.

Nine times out of ten the form is fine. The mail it sends is being rejected or filed as spam, because the domain never told anyone it was allowed to send.

What the receiving server sees

When your site sends a message, it goes out with a From address on your domain. The receiving server looks at that domain and asks a simple question: has this domain published a list of servers permitted to send on its behalf, and is this message coming from one of them?

If the answer is no, because no SPF record exists or because the record does not include the server the site actually uses, the receiver has a message claiming to be from your domain and arriving from somewhere unauthorised. That is exactly what forged mail looks like. Some receivers file it as spam. Some reject it silently. Nobody sees an error.

The three records

SPF is a DNS TXT record listing the servers allowed to send mail for the domain. If the site sends through a transactional provider, that provider’s include must be in the record. If it sends through the web host’s own mail server, that server must be.

DKIM signs each outgoing message with a private key and publishes the public key in DNS. The receiver verifies the signature, confirming the message was not altered and genuinely originated from the domain. Most transactional providers give you the DKIM record to publish during setup.

DMARC ties the two together. It tells receivers what to do when SPF or DKIM fails, and lets you receive reports on who is sending mail in your domain’s name. Start with a policy of none to collect reports, then tighten it. The DMARC project publishes the specification and a plain overview.

Publish all three when the site launches, not when the first complaint arrives.

The site’s mail and the team’s mail

Here is where site builders often leave a gap.

A site sends transactional mail from a role address: noreply@, orders@, notifications@. That address has to exist on the domain, and someone has to receive replies to it, because customers reply to receipts.

At the same time, the business behind the site needs its own mailboxes: contact@, support@, the owner’s name. If the client is still running the business from a free personal address while the site sends mail from a domain that has no real mailboxes, two things go wrong. Replies to transactional mail vanish, and the client’s own correspondence arrives from an address that does not match the site they just paid for.

A business email service on the client’s domain fills both roles. The site’s transactional addresses can be real mailboxes or aliases that forward somewhere useful, and the team’s own addresses live on the same domain with the same authentication records covering them.

A launch checklist

• SPF record published and including every service that sends for the domain
• DKIM record published for the transactional provider and for the mailbox provider
• DMARC record published, starting at p=none with a reporting address that someone reads
• Every role address the site sends from exists and is monitored
• Contact form tested by submitting it and receiving the result at a real external address
• Password reset tested against a Gmail and an Outlook account, since those two filter differently

Why this lands on the developer

Nobody else on the project touched DNS. When mail fails, the client asks the person who built the site, and “that is not my department” is a poor answer when it takes fifteen minutes during the build.

Add it to the handover document alongside the admin credentials, and it stops being a support ticket you will receive three weeks after launch.