trustyourinbox

EmailOctopus SPF and DKIM setup

EmailOctopus verifies a sending domain with four CNAME records and one TXT record, and it will not call the domain fully Verified until the TXT record, which is your DMARC policy, is in place. Here is what each record does, why there is no SPF record to add, and why an unverified sender goes out through an EmailOctopus domain instead of yours.

Verified 2026-09-06 against the official EmailOctopus documentation.

What you are setting up

EmailOctopus is a newsletter platform, and it verifies senders two ways: a single email address (you click a link in a confirmation email) or a whole domain (you publish DNS records). Only the domain route authenticates you. With an address-only sender, EmailOctopus routes the message through one of its own domains and recipients can see a “sent via” label naming a host such as sp.eomail5.com. Verify the domain and every address under it becomes usable as a From address with no further verification, and link tracking moves onto your own domain too. The record set is unusual for a newsletter tool: four CNAMEs and one TXT, no SPF record, because EmailOctopus puts the SPF-checked return path on a subdomain it names for you.

Publish SPF and DKIM

In EmailOctopus, open the Senders screen, click Verify new sender, then Verify domain (recommended). Enter the domain as yourdomain.com (no www, no https) and click Start verification. The page that follows lists four CNAME records and one TXT record; keep it open. If your DNS is on Cloudflare or Vercel, an Add records automatically button publishes all five through Domain Connect and you only approve them on the next screen. Otherwise, add them by hand. The shape is:

Type:  CNAME   (x4; DKIM plus the return-path subdomain)
Host:  (the names shown on your Start verification page, each ending in yourdomain.com;
        one of them is eom.yourdomain.com)
Value: (the target shown next to each name)

Type:  TXT     (DMARC)
Host:  _dmarc.yourdomain.com
Value: v=DMARC1; p=none;

Copy the names and values exactly as EmailOctopus prints them. The documentation names only one of the four CNAME hosts, eom.yourdomain.com; the others are specific to your account and appear only on your verification page, so this article does not guess at them. EmailOctopus is explicit that generating no SPF record is not a mistake: it creates eom.yourdomain.com as the return path (the “mail from” domain) for everything it sends for you, and it publishes and maintains the SPF for that subdomain itself. You can confirm it with any SPF lookup tool by querying eom.yourdomain.com rather than your root. Your existing root SPF record, whatever it says, is untouched and spends no lookups on EmailOctopus.

Once the records are in, return to EmailOctopus and click Complete verification. A Failed status right after adding the records is usually a host-name problem: many DNS hosts append your domain to whatever you type, so eom.yourdomain.com becomes eom.yourdomain.com.yourdomain.com. EmailOctopus's own fix is to re-enter every CNAME with only the label, so eom.yourdomain.com becomes eom. If the records are right and it still will not verify, wait a few hours for propagation and click again.

Add DMARC

The TXT record on the verification page is your DMARC policy, and EmailOctopus treats it as part of verification: without it the domain sits at Partially verified (DKIM and SPF found, DMARC missing). EmailOctopus generates this record for every new domain and recommends starting in monitor mode:

Type:  TXT
Host:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

The value EmailOctopus hands you is the bare v=DMARC1; p=none;. Add a rua address before you publish it, or you will have a policy and no reports, which is the half of DMARC that tells you whether EmailOctopus is actually passing. Build the full record with our DMARC builder. If your domain already has a DMARC record, keep it and skip the TXT; EmailOctopus says an existing policy satisfies the check, and a domain may only have one. Two alignment notes: EmailOctopus mail aligns on DKIM at your domain and on SPF through the eom subdomain, which passes under DMARC's default relaxed mode. If you ever set aspf=s, SPF alignment for EmailOctopus mail ends, and DKIM carries it alone, so leave SPF alignment relaxed. And when your reports are clean, progress past p=none.

The EmailOctopus gotcha

An unverified sender goes out through an EmailOctopus domain. EmailOctopus documents this for free addresses: send from thomas@gmail.com and the campaign goes out as thomas.gmail.com@send.eocampaign1.com, with a “sent via” label naming an EmailOctopus host such as sp.eomail5.com. An address-only verification on your own domain gets the same routing: the message is sent through and signed by an EmailOctopus domain, not yours. Replies still reach your inbox and the address looks familiar at a glance, so nothing appears broken. But as far as DMARC is concerned the mail is not yours. If the From stays on your domain while the signature and return path are EmailOctopus's, the message fails DMARC for your domain and shows up in your reports as a failing source; if the From is rewritten to an EmailOctopus address, it never appears in your reports at all, and your recipients are being trained to trust a domain you do not control. The fix is the domain verification above. Once the domain is Verified the mail is sent as you.

Partially verified is not verified. It means the four CNAMEs resolved and DKIM and SPF are working, but the DMARC TXT is missing. EmailOctopus warns that some receivers refuse bulk mail from domains without a DMARC policy, which is the Gmail and Yahoo rule for senders over 5,000 messages a day. Click the yellow status, copy the DMARC record, publish it, and click Complete verification again. Two smaller surprises: the return-path subdomain is eom.yourdomain.com, so if you see eom. in a Return-Path header or a reporting tool that is EmailOctopus, not a stranger. And if you use EmailOctopus Connect, none of this applies; you are sending through your own Amazon SES account, and the DKIM, SPF, and DMARC records are SES's, covered in our SES guide.

Confirm it worked

  • Check the Senders screen. The domain should carry a Verified label, not the yellow Partially verified one. Any address under it can now be a From address without its own verification.
  • Send a real campaign and read the headers. Open the message at the other end and confirm the From address is still you@yourdomain.com (not rewritten to an EmailOctopus address), the DKIM signature shows d=yourdomain.com, the Return-Path is on eom.yourdomain.com, and the result is dmarc=pass. Our header analyzer reads it back plainly.
  • Watch the reports. EmailOctopus should appear in your DMARC aggregate reports as an aligned source passing both SPF and DKIM, and trustyourinbox labels it as a known sender. If EmailOctopus is missing from the reports entirely while campaigns are going out, the mail is almost certainly still going out through an EmailOctopus domain.

Let trustyourinbox publish EmailOctopus for you.

Connect Cloudflare or AWS Route 53 once and the EmailOctopus records are one click. We email you the exact record, wait five minutes, write it, and read it back from public DNS. Then we keep watching this sender in your DMARC reports and alert you when EmailOctopus mail starts failing.

Was this page helpful?

Keep reading.

Start with one domain. See it with your own data.

Free for one domain, no card. Add one DNS record and the first reports usually arrive within a day.

  1. Monitoring
  2. Quarantine
  3. Reject