How to Fix Email Authentication When Your Host Sends Mail for You

Email deliverability on your own domain depends on the sending server proving it is allowed to send for you, and that proof lives in DNS, not in your mailbox. When your host relays mail through its own infrastructure, you are delegating the envelope but not the reputation, so you have to line up SPF, DKIM, DMARC and alignment with whatever the provider's outbound path actually does.

The core problem is that mail leaves your host's servers with your domain in the headers, and receiving systems check whether the network that connected to them is authorised by your DNS. If the answer is no, the message is at best marked as suspicious and at worst dropped before anyone sees it. Everything below is about closing that gap.

What the receiving server actually checks

When a remote mail server accepts a connection, it records the IP that connected. It then reads the envelope sender from MAIL FROM and the visible headers. SPF is evaluated against the envelope sender's domain, not the From: header. DKIM is evaluated against a signature added by the sending infrastructure, verified with a public key you publish. DMARC ties the two together by requiring that at least one of them aligns with the domain in From:.

Alignment is the part people miss. A host can pass SPF for its own bounce domain and pass DKIM with its own key, and DMARC will still fail because neither aligns with your From: domain. You want either SPF alignment, where the envelope domain is yours or a subdomain of yours, or DKIM alignment, where the d= tag in the signature is your domain.

Reading the headers before you change anything

Do not guess. Send a message to a mailbox you control that lets you view raw source, then pull the authentication results. A quick way to extract the relevant lines is to save the raw message and grep it.

grep -Ei '^(Received|Authentication-Results|DKIM-Signature|Return-Path|From):' message.eml

The output will look roughly like this, though the exact wording depends on the receiving system.

Return-Path: <[email protected]>
Authentication-Results: mx.example.net;
  spf=pass [email protected];
  dkim=pass header.d=host-relay.example;
  dmarc=fail (p=NONE) header.from=yourdomain.example
DKIM-Signature: v=1; a=rsa-sha256; d=host-relay.example; s=selector1;

That block tells you the whole story. SPF passed but for the relay's domain, DKIM passed but signed by the relay's domain, and DMARC failed because neither aligns with yourdomain.example. Fixing this is a conversation with your provider plus a DNS change on your side.

Fixing SPF when the host sends for you

Your SPF record is a single TXT record at the apex of your domain. It must include the sending infrastructure the host uses, and it must stay under the lookup limit of ten DNS mechanisms. The provider should publish a mechanism you can include, or at minimum tell you which IP ranges to list.

yourdomain.example.  TXT  "v=spf1 include:relay.example include:_spf.otherprovider.example -all"

Two rules matter here. First, use -all rather than ~all once you are confident the list is complete, because soft fail invites receivers to treat unauthorised senders leniently. Second, never add a second SPF record. Multiple v=spf1 TXT records at the same name cause a permanent error, and receivers will treat the domain as having no valid policy.

If your host rewrites the envelope sender to its own bounce domain, SPF will never align with your From: domain. In that case you are relying entirely on DKIM alignment, which brings us to the next section.

DKIM alignment and the selector you publish

DKIM requires a private key held by the sender and a public key you publish at selector._domainkey.yourdomain.example. If the host signs with its own key, you get authentication but not alignment. The fix is to have the provider sign with a key whose d= tag is your domain, or to relay outbound mail through a service that lets you supply your own key.

You can verify what is published with a DNS query.

dig +short TXT selector1._domainkey.yourdomain.example

The answer should be a v=DKIM1 record containing a p= public key. If it returns nothing, the selector is wrong, the record is missing, or you are querying the wrong name. Remember that a DKIM key can be revoked by publishing an empty p= tag, and that some receivers cache DNS longer than you would like, so plan key rotations in advance.

Publishing DMARC without breaking your mail

DMARC is a TXT record at _dmarc.yourdomain.example. Start in monitoring mode, collect reports, and only then move to enforcement. The reporting address needs to be a mailbox you actually read.

_dmarc.yourdomain.example.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=s; aspf=s"

The adkim and aspf tags set strict or relaxed alignment. Strict requires an exact domain match, relaxed allows subdomains. If your host sends from a subdomain of your domain, relaxed alignment is usually the pragmatic choice. Once reports show that legitimate mail passes consistently, raise p to quarantine and eventually reject.

One caution: if you run a mailing list, a ticketing system or a contact form that sends through a different path, those paths need their own SPF inclusion and DKIM signing, or they will fail under enforcement. Inventory every system that sends as your domain before you tighten policy.

What to do next

Start by capturing a raw message and reading the authentication results, because that tells you which of the two alignment paths is already working. Then ask your provider two direct questions: does your outbound path sign with a key under my domain, and does it rewrite the envelope sender. Publish or correct the SPF and DKIM records based on the answers, set DMARC to p=none with a reporting address, and leave it there until the reports are clean. Only then move to enforcement, and re-check every sending system you own before you do.