Authenticating Mailjet: SPF, DKIM and DMARC alignment

example.com.  IN TXT  "v=spf1 include:spf.mailjet.com ~all"

mailjet._domainkey.example.com.  IN TXT  "k=rsa; p=MIGfMA0GCSqGSIb3DQEB…"

Alignment: the DKIM signature carries compliance

DMARC is not satisfied with an SPF or a DKIM that merely "passes": it requires that at least one of the two mechanisms validate a domain aligned with the one in the From: field — the one the recipient sees in the mailbox. That is the standard's central concept, and it is what separates ESPs from one another.

At Mailjet, the DKIM signature is applied with the customer's domain: a message sent with From: contact@example.com carries a d=example.com signature. Signing domain and visible domain are identical — DKIM alignment is achieved, in strict mode as in relaxed mode. The result: DMARC passes, whatever policy is published, p=none today or p=reject tomorrow.

This is the property to take away from the whole article: at Mailjet, DMARC compliance rests on DKIM. As long as the mailjet._domainkey key sits in the zone and the signature is active, the flow is compliant. The SPF include serves reputation and deliverability, but it is not what makes DMARC pass — the next section explains why.

To place this building block within the whole setup — policy, reporting addresses, tags —, the hub of annotated record examples, policy by policy serves as the reference: the _dmarc record is spelled out there from plain monitoring all the way to reject.

Envelope and Return-Path: where SPF alignment stops

What remains is understanding why SPF, for its part, will not align — and why that is fine.

SPF does not evaluate the visible From: but the envelope address: the MAIL FROM of the SMTP session, exposed after the fact in the Return-Path header. Like most ESPs, Mailjet places in that envelope a technical domain of its own (of the form bnc3.mailjet.com): that is what lets it collect bounces and process unsubscribes on the customer's behalf. The mechanical consequence: the receiving server checks SPF against Mailjet's bounce domain. The test succeeds — the sending IPs do sit in that domain's SPF — but the domain validated this way bears no relation to example.com: SPF passes without aligning, and contributes nothing to the DMARC verdict.

In aggregate reports, this behavior produces a puzzling read: spf=pass on one line, SPF alignment failing on the next, and yet a positive DMARC evaluation thanks to DKIM. That gymnastics is dissected in the article devoted to these seemingly contradictory verdicts, which teaches how to read those lines without panicking.

Some offers go further: depending on the plan, Mailjet allows the Return-Path to be customized through a CNAME — bounce.example.com pointing to the ESP's bounce infrastructure. The envelope then becomes a subdomain of the visible domain, and SPF alignment in relaxed mode becomes reachable. It is a useful refinement for reputation, not a prerequisite: aligned DKIM is enough for DMARC, and chasing double alignment only makes sense once the rest of the project is done.

A dedicated sending subdomain: the good practice

Nothing forces campaigns to leave from the organizational domain itself. The recommended practice — at Mailjet as elsewhere — is to delegate emailing to a dedicated subdomain: news.example.com for marketing, keeping example.com for human correspondence and, say, billing.example.com for transactional flows.

The benefits are concrete. First, reputation isolation: a campaign incident — a complaint spike, a poorly cleaned list — degrades the reputation of the sending subdomain, not that of the main domain on which everyday exchanges depend. Second, report readability: each subdomain tells the story of one flow, and an unexpected source stands out there at a glance. Third, policy flexibility: DMARC can treat subdomains specifically (the sp= tag, complemented by np= for non-existent subdomains), and DMARCbis — the current standard — discovers the applicable policy by walking up the DNS tree, the Tree Walk, subdomain by subdomain.

Concretely, the procedure stays the same, one level down: validating news.example.com at Mailjet, publishing the SPF include and the DKIM key on that subdomain (mailjet._domainkey.news.example.com), and letting relaxed alignment — the default mode — bridge to the organizational domain: a From: letter@news.example.com signed d=news.example.com remains aligned with example.com.

The reasoning holds for every router, each with its own envelope and selector quirks: the guides devoted to authentication at Brevo and to the SendGrid-side setup follow the same blueprint, and comparing the three is instructive.

The mistakes seen in the field

DNS zones audited after a "DKIM won't pass" almost always tell one of these four stories.

• The duplicated SPF. The registrar's wizard or an over-hasty copy-paste creates a second v=spf1 record next to the existing one, instead of merging the mechanisms into a single record. Two SPF records on the same name produce a permerror: recipients ignore both, and a mechanism meant to help turns into a systematic failure for every flow on the domain, not just Mailjet's. The fix fits on one line: a single v=spf1, every include inside it.
• The record placed at the wrong level. A classic of DNS interfaces that automatically append the zone name: the key ends up published at mailjet._domainkey.example.com.example.com — the domain doubled — because the full name provided by Mailjet was pasted into a field expecting a relative name. A frequent variant: the SPF include added on example.com while the validated domain, the one used in the From:, is news.example.com — or the reverse, the DKIM key placed on the apex while the sends leave from the subdomain. In every case, Mailjet's check stays red or, worse, turns green on a scope that is not the one the real sends use.
• The truncated key. A p= value clipped during pasting — a field too short, lost quotes, a stray line break — produces an unverifiable signature. A dig TXT mailjet._domainkey.example.com allows a character-by-character comparison between the published value and the one the platform provided.
• The signature never activated. The record sits properly in the zone, but the final verification on the Mailjet side was never re-run: messages leave without a signature from the domain itself. The DNS is correct, the flow is not — the most frustrating case, because it is invisible from the zone.

None of these mistakes is serious; all of them cost days of degraded deliverability when nobody watches the right signals. Hence the final step.

Verification in the reports

The configuration is not declared finished when the interface turns green: it is verified in the aggregate reports. With a DMARC record publishing a collection address:

_dmarc.example.com.  IN TXT  "v=DMARC1; p=none; rua=mailto:reports@example.com"

every major recipient — Gmail, Microsoft, Yahoo — sends a daily digest of the messages received in the domain's name, IP by IP, verdict by verdict.

In those reports, a properly configured Mailjet flow shows three telltale signals: the platform's sending IPs appear as an identified source; DKIM shows pass with a signing domain equal to the From: domain — the alignment; SPF shows pass on Mailjet's bounce domain, without alignment, which is the expected behavior and not an anomaly. If DKIM fails, or if the signature carries a Mailjet domain instead of the domain itself, one of the mistakes from the previous section is very probably the cause.

That reading is also the guardrail for hardening: moving from p=none to p=quarantine and then p=reject presupposes several weeks of reports in which the Mailjet flow — and every other legitimate sender — stays aligned without exception. DMARCbis, incidentally, provides an explicit test mode (t=y) to flag a policy still being broken in, where the old pct tag has disappeared from the standard.

In summary

Authenticating Mailjet follows a short, well-marked path: validating the domain — or, better, the dedicated sending subdomain —, an spf.mailjet.com include merged into the existing SPF record, a DKIM key published under mailjet._domainkey, a signature activated and then checked. DMARC compliance rests on DKIM, signed with the domain itself; SPF passes without aligning because of the ESP's technical Return-Path, and that is normal behavior, optionally correctable with a custom Return-Path. The failures met in the field rarely come from the standard: they come from a duplicated SPF, a record placed at the wrong level, a key truncated or never activated — all diagnoses that can be read in black and white in the aggregate reports.

To know where a domain stands, before or after this project, a free DMARC analysis draws up the state of play in a few seconds: published records, includes present, policy in force. And to follow the reports over time, all the way to p=reject, opening an account gives access to continuous monitoring of the domain — Mailjet flow included.