Adding a new service that sends email as your domain

Each service that sends email as your domain needs its own entry in your domain's email authentication. Your mail system, your website's form notifications, your CRM's campaigns, your ERP's purchase orders: if any of them sends from an address at your domain without being listed, receiving mail servers increasingly treat its messages as forged. That is why an order confirmation from a new system can vanish while ordinary email works perfectly.

For what SPF, DKIM, and DMARC are, see email authentication for your domain. This article is about adding a sender, and about the reports DMARC sends.

Before you add a sender

1. Ask the vendor for their instructions for SPF and DKIM. Most publish them: an include: for SPF and one or more DKIM records, often CNAMEs.
2. Decide the From address, such as orders@ or noreply@, and use a subdomain for bulk marketing if you can.
3. Check your current SPF record. A domain may have only one SPF record, and it can contain at most 10 DNS lookups.

Updating SPF safely

Add the new service to the existing record; never create a second SPF record. For example:

Before: v=spf1 include:_spf.google.com ~all
After:  v=spf1 include:_spf.google.com include:mail.vendor-example.com ~all

Too many includes break SPF entirely, so remove services you no longer use whenever you add one.

Turning on DKIM

DKIM signs each message so receivers can verify it. The vendor gives you DNS records to publish; once they resolve, you switch DKIM on in the vendor's settings. DKIM is what keeps mail passing DMARC when SPF alone cannot, such as for forwarded mail.

DMARC reports: the flood of XML emails

A DMARC record can ask mail providers to send reports to an address you choose. Aggregate reports (the rua= tag) arrive as daily XML attachments from Google, Microsoft, and others. They are invaluable while you are finding every service that sends as your domain, and noise once you are done. If someone's inbox is filling with them:

• Send them to a dedicated mailbox or a DMARC reporting service, not a person
• Do not delete the DMARC record itself; only change or remove the reporting address
• Keep reporting on while you are still moving toward a stricter policy

When a sender's mail lands in spam

• Check the message headers for SPF, DKIM, and DMARC results; "fail" names the gap
• Confirm the From domain matches the domain the service signs for
• Check whether your DMARC policy recently became stricter
• Check the service's own logs for bounces or blocks

Services that commonly send as your domain

• Your main mail system, such as Microsoft 365 or Google Workspace
• Website forms and notifications
• Newsletter and marketing platforms
• CRM, ticketing, and help desk tools
• ERP, accounting, and order systems sending invoices and purchase orders
• Scanners, copiers, and alerting systems

Keeping a list like this, with an owner for each, makes the next addition a five-minute task.

Moving to a stricter DMARC policy

1. Start with p=none and reporting on, so nothing is blocked while you learn.
2. Read the reports, or a reporting service's summary, until every legitimate sender passes.
3. Move to p=quarantine, optionally for a percentage of mail first.
4. Move to p=reject once nothing legitimate is failing.

Common questions

Can the website send as a visitor's address? No; use your own address as From and the visitor's in Reply-To; see contact form emails not arriving.

Who should own these records? Whoever manages your DNS, working from a list of approved senders that IT keeps current.

We switched sending services and some forms stopped. Check that every form's From address uses the newly verified domain or address, and that the old service's records were not removed before the new ones validated.

Can a vendor send from our main address? It can, if it is authorized in SPF and signs with DKIM for your domain. A dedicated address or subdomain keeps its reputation separate from your staff email.

How eWay handles sending services

Website email on environments eWay manages goes out through an authenticated sending service, such as Amazon SES or your organization's mail relay. When the sending service changes, eWay provides the exact SPF, DKIM, and verification records to add and confirms delivery afterwards. If eWay manages your DNS, eWay can add them for you.

What to include in a support ticket

• The service, the From address, and the vendor's instructions
• Your current SPF and DMARC records, if you have them
• For delivery problems: a message's full headers

eWay customers can open a ticket in the support portal or email support@ewaycorp.com. Related reading: requesting a DNS change.