Email authentication for Mailjet: SPF, DKIM and DMARC

4 May 2026 · 15 min read

Mailjet sends your mail from shared infrastructure, and it stamps its own bounce address onto every message. Those two facts decide exactly how you authenticate a domain on Mailjet, and they are also why a generic SPF, DKIM and DMARC checklist will quietly mislead you. The thing most guides tell you to publish for SPF does not help DMARC at all on Mailjet's default setup, and the thing that actually carries DMARC, DKIM, is the part people rush.

This guide is specific to Mailjet. It covers the exact SPF include Mailjet hands you and why you can largely ignore it, how Mailjet's DKIM works and what the mailjet selector looks like, why the return-path is bnc3.mailjet.com and what that means for alignment, how to set a custom return-path so SPF aligns too, and the staged path to p=reject without losing a single legitimate message. Read the guide for the provider you actually use, because alignment behaviour differs between providers and a one-size template is where outages come from.

The three identities that travel with a Mailjet message

Every email carries three separate pieces of identity, and DMARC judges them against each other:

• The From header, the address recipients see, for example hello@yourdomain.com. This is the identity DMARC protects.
• The DKIM signature, a cryptographic signature whose d= tag names the domain that signed the message.
• The return-path, also called the envelope-from or MAIL FROM, the address bounces go back to. This is the domain that SPF checks.

DMARC does not pass simply because SPF or DKIM pass. It passes when at least one of them passes and aligns: the authenticated domain must match the organisational domain in the From header. You only need one aligned identifier, not both. That single rule is the whole game on Mailjet, so it is worth fixing in your mind before you touch DNS. If the term is fuzzy, the glossary entry on DMARC alignment lays it out, and the return-path entry explains the envelope-from specifically.

Why Mailjet is different from your own mail server

On your own mail server you control the sending IP and the bounce address, so you can make both SPF and DKIM align with your domain trivially. Mailjet is not that. By default:

• Mailjet sends from a shared pool of IP addresses used by many customers, reached through the SMTP host in-v3.mailjet.com.
• The return-path is Mailjet's own domain, bnc3.mailjet.com, not yours.

When a receiver runs SPF, it checks the return-path domain. On Mailjet's default setup that domain is bnc3.mailjet.com, so SPF is evaluated against Mailjet, sees Mailjet's own published SPF, and passes for Mailjet. But because the return-path is bnc3.mailjet.com and your From header is yourdomain.com, SPF does not align with your domain. SPF passes; SPF alignment fails. That is not a misconfiguration you can fix by editing your own SPF record. It is how the shared return-path works.

That leaves DKIM to carry DMARC. Mailjet signs your outgoing mail with a key whose d= matches your domain, so DKIM passes and aligns, and DMARC passes on the DKIM side. The practical consequence, stated plainly:

On Mailjet's default setup, DKIM is the load-bearing mechanism for DMARC. SPF alignment is not available until you configure a custom return-path. Get DKIM right and you can reach p=reject safely. Misunderstand it and you will chase an SPF alignment that cannot happen on the default bounce domain.

You can confirm exactly what is aligning for your live Mailjet traffic with the DMARC report analyzer, which breaks aggregate reports down by source so you can see Mailjet's mail and whether it is passing on DKIM, SPF, or both.

Step 1: add and verify your domain in Mailjet

Do the DNS work from Mailjet's generated values, never from a blog post, because the DKIM key and selector are account- and key-specific.

1. Log in to Mailjet and open Account settings, then Domains and DNS (sometimes shown as Sender domains and addresses).
2. Click Add a sender domain (or Add a new domain) and enter your sending domain, for example yourdomain.com.
3. Mailjet generates the records you need: a TXT verification record and the DKIM record, and it displays the SPF record for reference.

A common, clean pattern is to dedicate a subdomain to Mailjet, for example news.yourdomain.com for marketing or mg.yourdomain.com for transactional, so this stream's reputation is isolated from your corporate mailbox mail. If you do that, add and authenticate that exact subdomain in Mailjet and publish the records under it. Because DMARC uses relaxed alignment against the organisational domain by default, a DKIM signature on news.yourdomain.com still aligns with a From of you@news.yourdomain.com and with the parent yourdomain.com.

Step 2: publish the verification TXT record

Mailjet gives you an ownership-verification TXT record. It proves you control the domain and unlocks authenticated sending. It plays no part in SPF, DKIM or DMARC, but Mailjet will not finish validating the domain until it resolves. It looks like a TXT record at the domain root:

Type:  TXT
Host:  @            (i.e. yourdomain.com)
Value: mailjet-validation=abc123def456...

Some DNS hosts want the host field left as @ or blank for the root; others want the full yourdomain.com. Publish it and move on; you do not need to wait for it before adding the rest.

Step 3: enable and publish DKIM (the part that matters most)

DKIM is what makes DMARC pass on Mailjet, so this is the step to get exactly right.

Mailjet generates a DKIM key pair and shows you a single public-key TXT record to publish. For domains created from 25 April 2024 onward, Mailjet creates 2048-bit DKIM keys by default; older domains may still carry a 1024-bit key, which you can rotate up. The selector Mailjet uses is mailjet, so the record lives at the host mailjet._domainkey.yourdomain.com. The published value is a standard DKIM TXT string:

Type:  TXT
Host:  mailjet._domainkey.yourdomain.com
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

The p= value is a long Base64 string and is unique to your domain. Copy it character for character from your Mailjet dashboard, and copy the selector exactly as shown; do not type either from this article.

Three practical points that catch people out:

• Host field doubling. Some DNS providers want the bare label mailjet._domainkey and append your domain automatically. Others want the fully qualified mailjet._domainkey.yourdomain.com. If you enter the full host on a provider that also appends the domain, you get a broken record like mailjet._domainkey.yourdomain.com.yourdomain.com, and validation fails. If DKIM will not verify, this doubling is the first thing to check.
• The 2048-bit key and TXT length. A 2048-bit public key is long enough that some DNS UIs split it across multiple quoted strings. That is fine as long as the strings concatenate to the single value Mailjet gave you. Do not insert spaces or line breaks inside the Base64 yourself.
• Cloudflare proxying. If your DNS is on Cloudflare, a DKIM TXT record cannot be proxied (TXT records have no orange cloud), so that specific trap does not apply here, but do make sure you have not accidentally truncated the record on paste. If you are migrating from a CNAME-style DKIM on another provider, remove any stale _domainkey records that conflict.

Once the record resolves, return to Mailjet and click Check now (or Validate). A correct record shows a green tick next to DKIM. Independently confirm the signature is live and well-formed with the DKIM checker, entering your domain and the selector mailjet. If you want the background on how selectors and rotation work, see DKIM selectors explained and the DKIM key rotation glossary entry.

Step 4: SPF, and why Mailjet itself says you can skip it

This is where generic guides steer you wrong. The SPF record Mailjet displays is:

Type:  TXT
Host:  @
Value: v=spf1 include:spf.mailjet.com ?all

Note the qualifier: Mailjet publishes ?all (neutral), not ~all (softfail). And here is the part most checklists omit. Mailjet's own documentation tells you that you do not need to publish this SPF record for Mailjet to authenticate, because on the default return-path the SPF check runs against bnc3.mailjet.com, not your domain. Even with a perfect include:spf.mailjet.com published on yourdomain.com, your Mailjet mail will not produce aligned SPF, because the envelope-from is not your domain. DMARC on default Mailjet passes through DKIM alignment only.

So should you publish the include or not? The honest position:

• It does not make DMARC pass for Mailjet, and Mailjet does not require it for domain validation.
• It is harmless and good hygiene, and it can help some receivers' non-DMARC reputation heuristics.
• It becomes genuinely load-bearing only if you configure a custom return-path on your own domain, covered in the next step. Then SPF is evaluated against your domain and the include starts to matter.

The thing not to do is assume that adding include:spf.mailjet.com is what gets you to enforcement. On the default setup it is DKIM that does that work. Equally, do not bloat your single SPF record with every provider you have ever trialled. SPF allows a maximum of 10 DNS lookups, and include:spf.mailjet.com consumes at least one. If your record is creeping toward the limit, validate it with the SPF checker and read how to fix SPF PermError from too many lookups. For provider-by-provider SPF guidance, see SPF for common providers.

A single domain must have exactly one SPF TXT record. If you already send through, say, Google Workspace and Mailjet, merge them into one line:

Type:  TXT
Host:  @
Value: v=spf1 include:_spf.google.com include:spf.mailjet.com ~all

Never publish two separate v=spf1 records; receivers treat that as a permanent error and SPF stops working entirely. Note that when you merge, you choose the trailing qualifier for the whole record; ~all (softfail) is the usual choice for a combined record, even though Mailjet's standalone example uses ?all.

Step 5: custom return-path and SPF alignment on Mailjet

By default you cannot change Mailjet's envelope-from, and that is fine, because DKIM carries DMARC. But if your internal policy wants SPF aligned as well, perhaps because a downstream security tool grades on both, Mailjet supports a custom return-path on a paid plan. The mechanism is a single CNAME plus a support request.

First, publish a CNAME that delegates a bnc3 subdomain of your domain into Mailjet's bounce infrastructure:

Type:  CNAME
Host:  bnc3.yourdomain.com
Value: bnc3.mailjet.com

Then open a ticket with Mailjet support asking them to activate a personalised (custom) return-path for your domain. Attach a screenshot of the CNAME and include the API key associated with the sending domain, because the custom return-path is configured per API key and you can have one active custom return-path per key. Once Mailjet activates it, your messages go out with an envelope-from of bnc3.yourdomain.com instead of bnc3.mailjet.com.

With that in place, SPF is now evaluated against your domain. The lookup follows the CNAME to bnc3.mailjet.com, which resolves to Mailjet's published SPF, so SPF passes; and because the envelope-from is now bnc3.yourdomain.com, it aligns with a From of yourdomain.com under relaxed alignment (same organisational domain). At that point your include:spf.mailjet.com record is doing real work and you have both SPF and DKIM aligned, the most robust position.

Two caveats to be honest about:

• This is optional polish on top of DKIM, not a prerequisite for DMARC. If you never set a custom return-path, aligned DKIM alone gets you to p=reject.
• The custom return-path is a paid-plan feature activated through support, not a self-service toggle, so plan for the ticket turnaround.

Step 6: the DMARC record and reaching enforcement

DMARC ties everything together. It tells receivers what to do when a message fails both aligned SPF and aligned DKIM, and where to send you reports. You publish it once at _dmarc.yourdomain.com, regardless of how many providers you use. Do not start at p=reject. Stage it.

Stage 1: monitor. Publish a p=none record with reporting on:

Type:  TXT
Host:  _dmarc.yourdomain.com
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1; adkim=r; aspf=r

p=none changes nothing about delivery; it just asks receivers to send aggregate reports (rua). adkim=r and aspf=r request relaxed alignment, which is what lets a news.yourdomain.com DKIM signature align with the yourdomain.com organisational domain. Build a correct record with the DMARC generator and validate an existing one with the DMARC checker.

Stage 2: read the reports. Let it run for one to two weeks of normal sending. Aggregate reports arrive as XML, which is unreadable by eye, so feed them to the DMARC report analyzer. You are looking for one thing first: is Mailjet traffic passing DMARC via aligned DKIM? It should show your Mailjet-sent volume with DKIM pass and DKIM aligned. If you have set up a custom return-path, you should also see SPF aligned. Crucially, confirm every other legitimate source is aligned too, your own mailbox provider, any helpdesk, any invoicing tool, because DMARC enforcement is domain-wide and hits all of them, not just Mailjet. For how to read what you are seeing, DMARC alignment explained walks through a real report.

Stage 3: quarantine, partially. Once Mailjet and your other sources are consistently aligned, step up cautiously with the percentage tag:

Type:  TXT
Host:  _dmarc.yourdomain.com
Value: v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourdomain.com; fo=1; adkim=r; aspf=r

pct=25 applies quarantine to a quarter of failing mail, limiting blast radius while you watch reports. If nothing legitimate is being quarantined, raise to pct=50, then pct=100.

Stage 4: reject. When p=quarantine; pct=100 has run clean, move to full enforcement:

Type:  TXT
Host:  _dmarc.yourdomain.com
Value: v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; fo=1; adkim=r; aspf=r

At p=reject, anything failing aligned authentication is rejected outright, which is exactly what stops criminals spoofing your domain. Because you reached this point by confirming Mailjet's aligned DKIM at every stage, your Mailjet mail keeps flowing. For a provider-independent walk-through of the staged rollout, see how to reach p=reject without breaking email and the longer-form enforcement journey. For the mailbox-provider rules driving all of this, see the bulk sender requirements.

A note on subdomains and the sp tag

If you send Mailjet mail from a subdomain such as news.yourdomain.com, remember that DMARC at the organisational domain applies to subdomains unless you override it. You can set a separate subdomain policy with the sp tag, which is useful if you want the parent domain at p=reject but a subdomain still at p=quarantine while you finish onboarding it:

Type:  TXT
Host:  _dmarc.yourdomain.com
Value: v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r

The subdomain policy (sp) glossary entry covers the interaction in detail. In most Mailjet setups you do not need sp at all, but it is the right tool if your subdomain stream is younger than the rest of your mail.

Common Mailjet authentication mistakes

• Expecting SPF to fix DMARC on the default setup. It cannot align, because the return-path is bnc3.mailjet.com. DKIM is the mechanism. Only a custom return-path makes SPF alignment possible.
• Skipping DKIM because SPF passes. SPF passing for Mailjet is not the same as SPF aligning for your domain. If DKIM is not set up, your Mailjet mail has no aligned identifier and will be quarantined or rejected the moment you enforce.
• The doubled host suffix. mailjet._domainkey.yourdomain.com.yourdomain.com from entering a full host on a provider that auto-appends the domain. The single most common DKIM validation failure.
• Truncating the 2048-bit key on paste. Copy the entire p= value; if your DNS UI splits it into chunks, that is fine, but the concatenation must equal Mailjet's value exactly.
• Two SPF records. One v=spf1 line only; merge providers into it. Two records is a permanent error.
• Mixing up ?all and ~all. Mailjet's standalone example uses ?all; a merged multi-provider record usually ends ~all. Either is acceptable; what matters is a single, valid record.
• Jumping straight to p=reject. Always monitor, then quarantine with pct, then reject.
• Forgetting other senders. DMARC is domain-wide. If your CRM, helpdesk or billing tool is not aligned, enforcement will hit it too.

Verify the whole chain

Before and after you reach enforcement, confirm each layer resolves:

• DKIM checker: query selector mailjet and confirm a valid 2048-bit key resolves.
• SPF checker: confirm a single valid record under 10 lookups, with include:spf.mailjet.com present.
• DMARC checker: confirm the policy, reporting address and alignment tags are what you intend.
• DMARC report analyzer: confirm Mailjet traffic is passing on aligned DKIM before you tighten the policy.

If you also publish MTA-STS or BIMI, note that BIMI requires p=quarantine or p=reject first, so reaching DMARC enforcement on your Mailjet domain is a prerequisite for a verified logo in the inbox. The deeper product pages, hosted DKIM, hosted SPF and managed DMARC, explain how we automate each layer.

The practical takeaway

For Mailjet the rule is short: DKIM does the work, SPF is optional, DMARC enforcement is reached through aligned DKIM. Publish the verification TXT, publish the mailjet._domainkey DKIM record (a full 2048-bit key, not truncated), add include:spf.mailjet.com for hygiene if you like, then move DMARC from p=none to p=quarantine to p=reject while watching aggregate reports to confirm Mailjet's DKIM is aligned at every step. If you want SPF aligned too, publish the bnc3 CNAME and ask Mailjet support to activate a custom return-path on a paid plan; that is polish on top of DKIM, not a prerequisite.

If you would rather not babysit selectors, percentages and XML reports, our done-for-you managed DMARC service takes your domain from p=none to p=reject with continuous monitoring and change alerts, and our free monitoring will email you the moment a Mailjet DKIM record stops resolving or your alignment slips. Start by running your domain through the DMARC report analyzer to see exactly how your Mailjet mail is authenticating today.