AWeber SPF, DKIM and DMARC: authenticating your sending domain

Before you touch DNS, fix the From address. If your AWeber broadcasts go out from a gmail.com, yahoo.com or other free-mail address, DMARC-enforcing receivers will reject or junk them — those providers publish p=reject on their own domains specifically to stop third-party platforms sending as their users. No DNS record on your side can override someone else's DMARC policy. Send from a domain you control, then authenticate it.

What the three records do here

• SPF authorises servers to use your domain as the *envelope* sender. Hosted platforms usually use their own bounce domain, so SPF often passes for the platform rather than for you.
• DKIM attaches a cryptographic signature using a key published in your DNS. This is the mechanism that gives hosted mail an aligned pass.
• DMARC tells receivers what to do when neither SPF nor DKIM passes *in alignment with your From domain*, and sends you reports about it.

For any hosted email platform, the practical goal is: aligned DKIM on your domain. Everything else is secondary.

Set up the sending domain

1. In AWeber, add and verify the domain you want in From. Use a real mailbox on that domain, not an alias forwarding elsewhere — platform verification mail has to arrive.
2. Take whatever DNS records the platform's domain-authentication screen issues — typically one or more CNAMEs under _domainkey — and publish them exactly as shown. The selector names and targets are account-specific; they can only come from your own dashboard.
3. Enter only the relative part of the host if your DNS panel appends the domain automatically. Otherwise you end up with selector._domainkey.yourdomain.com.yourdomain.com, which resolves to nothing.
4. Wait for the dashboard to confirm, then verify independently.

dig +short CNAME <selector>._domainkey.yourdomain.com
dig +short TXT   <selector>._domainkey.yourdomain.com

A CNAME-based setup is the better option when it is offered: the platform rotates the key behind the CNAME and you never have to republish a 2048-bit public key or fight your DNS host's 255-character string limit.

Prove it with a real message

Send a broadcast to a test address on Gmail and one on Outlook, then read the headers. In Gmail, *Show original*.

From: You <hello@yourdomain.com>
DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=<selector>; ...
Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=<platform bounce domain>;
  dkim=pass header.i=@yourdomain.com;
  dmarc=pass (p=NONE) header.from=yourdomain.com

The line that matters is d= in the DKIM-Signature header. If d=yourdomain.com, you are aligned. If d= shows the platform's domain, the signature is valid but unaligned, DMARC is passing on nothing, and moving to p=reject would break your broadcasts.

SPF: merge, never duplicate

If the platform documents an SPF include, merge it into your single existing record:

v=spf1 include:_spf.google.com include:<platform include> ~all

Two v=spf1 records on one domain is a specification violation: receivers return PermError and ignore SPF completely. Also respect the ceiling of 10 DNS-querying mechanisms (include, a, mx, exists, ptr, redirect) per evaluation, and the limit of two lookups that return nothing. If you are near the limit, give the platform its own subdomain — news.yourdomain.com — with its own SPF record and its own budget.

DMARC, in stages

Publish monitoring first:

_dmarc.yourdomain.com   TXT   "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1"

Run it for a week, read the aggregate reports, confirm your broadcasts show DKIM alignment on your domain, then move to p=quarantine and later p=reject. Set sp= explicitly if you send from subdomains — without it, subdomains inherit p=, which is either exactly right or exactly wrong depending on what else sends from them.

If rua points at a mailbox on a different domain, that domain must authorise the reports with a record of the form yourdomain.com._report._dmarc.<their-domain> containing v=DMARC1, or compliant receivers will discard the reports.

Choosing the From domain

Three reasonable options, in descending order of caution:

Marketing volume on a subdomain and human conversation on the apex is the configuration that fails safest.

What not to do

• Do not use a gmail.com or yahoo.com address in From for platform sends. It fails DMARC by design.
• Do not publish a second SPF record when adding the platform.
• Do not jump to p=reject before reports confirm every sender is aligned.
• Do not reuse a DKIM selector across two platforms — a collision silently replaces a working key.
• Do not treat a green tick in the dashboard as proof of DMARC alignment. The tick means the platform can send; the headers tell you whether receivers credit it to your domain.

MailPilot checks SPF, DKIM and DMARC for the sending domain behind each connected mailbox and measures where messages land per provider using a seed-inbox network, so you can tell an authentication problem apart from a reputation problem instead of guessing.