On this page: Before starting: domain, account and API-key scope · Publish Mailjet SPF without replacing other senders · Publish the account-generated DKIM public key · Optional: activate a custom Return-Path · Troubleshooting Mailjet-specific failures · Frequently asked questions · Publish DMARC without weakening existing protection · Verify DNS and trusted receiver evidence separately · Review scope and implementation boundary
Mailjet domain authentication requires your account's DKIM public key and the Mailjet SPF authorization. DMARC normally passes through aligned DKIM because Mailjet's default Return-Path uses its own domain. A custom Return-Path is a separate paid-account feature that requires support activation for the intended API key. Mailjet's current alignment explanation
This guide covers Mailjet campaigns and application mail sent through Mailjet SMTP or API. It does not configure a mailbox, change incoming mail routing, or authenticate unrelated Sinch services. Domain ownership, published DNS, Mailjet validation and authentication on a delivered message are four different checkpoints.
Before starting: domain, account and API-key scope
Make a worksheet with the visible From address, sending application, Mailjet account/API-key identity, DNS administrator and receiving test mailbox. Record identifiers without exposing credentials. Check which key the application actually uses rather than assuming the account shown in your browser is the production route. An application deployed months ago may still use a different subaccount.
Save the existing SPF policy, DKIM records and DMARC policy before changing anything. Keep the current nameservers and TTLs with that snapshot. A registrar is not necessarily the authoritative DNS host. If the domain is delegated elsewhere, editing the registrar's unused zone will not publish the records receivers query.
Mailjet permits domain validation as an alternative to validating individual sender addresses. Its documented allowance is 100 sender addresses and/or domains per API key. In the sender-domain screen, add the domain and use the issued TXT verification token or supported website-file method, then complete the check. Domain validation applies only to the API key used for verification; repeat it for each other subaccount that will send. Ownership validation is not DKIM activation. Domain-validation instructions
Publish Mailjet SPF without replacing other senders
Mailjet's documented SPF mechanism is include:spf.mailjet.com. For a domain whose only authorized sender is Mailjet, its help-center example is:
Owner: example.com
Type: TXT
Value: v=spf1 include:spf.mailjet.com ~all
Replace the example domain. For an existing SPF policy, add only the required mechanism before the final all, preserving other legitimate sources and the existing ending. Do not paste a second complete SPF policy into the same value or create a second SPF TXT record. Mailjet SPF and DKIM instructions
If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.
A Mailjet-generated default is not a complete inventory of your organization. Its developer documentation explicitly leaves merging existing SPF authorizations to the client. Even examples in different Mailjet documents use different final qualifiers, so do not treat an example as permission to change your established policy. Mailjet DNS API fields
SPF evaluates the SMTP MAIL FROM domain, generally visible in the delivered Return-Path, rather than the address readers see in From. Consequently, adding this include to example.com does not change a message whose envelope sender is still under bnc3.mailjet.com. Confirm the actual identity before diagnosing an apparent SPF alignment failure.
Publish the account-generated DKIM public key
Open the domain's SPF/DKIM authentication settings. Publish a TXT record at the owner displayed by Mailjet, normally mailjet._domainkey.example.com, with the complete account-generated public value. A typical value begins k=rsa; p=, but the key after p= must come from your own domain configuration, not a screenshot or this article. The current help center identifies 2048-bit keys as the default. Mailjet authentication settings
Use mailjet._domainkey only when the DNS editor appends example.com automatically. Check the saved fully qualified name. If authenticating news.example.com inside the parent zone, the relative owner would instead include news. A duplicated suffix creates a plausible-looking record at the wrong location.
For an issued signing domain such as news.example.com, the illustrative full owner is ISSUED-SELECTOR._domainkey.news.example.com. In an editor relative to the parent example.com zone use ISSUED-SELECTOR._domainkey.news; in a separately delegated news.example.com zone use ISSUED-SELECTOR._domainkey; in a delegated _domainkey.news.example.com zone use only ISSUED-SELECTOR. Replace the placeholder with the issued selector and preserve the exact account type and value. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.
DKIM records publish public information. SMTP passwords and API secrets never belong in DNS. Long TXT values may be displayed as several quoted strings in one record; DNS concatenates those strings. That is different from publishing several independent key records at one selector. Verify that the assembled value exactly matches the issued key. DKIM key publication standard
Recheck the domain in Mailjet after publication. The DNS API exposes separate SPF/DKIM statuses and a check action; the user interface shows authentication checks. Treat those as provider validation, not a substitute for a message sample. Do not regenerate a working key merely to refresh status. Mailjet validation behavior
Optional: activate a custom Return-Path
For paid accounts, Mailjet documents a CNAME such as:
Owner: bnc3.example.com
Type: CNAME
Target: bnc3.mailjet.com
Validate the chosen domain, publish the record, then request activation through Mailjet support for the intended API key. Only one custom Return-Path can be active per key. DNS publication alone does not activate it. Use the authenticated support channel for account details, not a public ticket or shared article comment. Custom Return-Path requirements
Choose an unused owner. A CNAME cannot share its owner with TXT, MX or other ordinary records; do not add an SPF TXT alongside this alias or overwrite a hostname serving another purpose. Confirm the target is treated as a hostname, not appended to your zone. These are separate owner and target fields, not one pasted zone-file line.
Where the actual authoritative DNS host offers these controls, use DNS-only aliases, not HTTP proxying or redirects, and keep a literal CNAME answer to each required target. Turn the relevant per-record Flatten option off when available, and ensure applicable zone-wide settings do not conceal the issued aliases. For Cloudflare specifically, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are Cloudflare behaviors, not assumed controls in another provider’s panel. If mandatory behavior or shared settings prevent the required CNAME answer, stop and coordinate a supported configuration without breaking dependent records. Do not blindly change the whole zone or remove an NS delegation; publish at the delegated authority when appropriate. Cloudflare CNAME verification, flattening controls.
For From example.com, an envelope domain bnc3.example.com can align under relaxed SPF alignment, but not strict alignment requiring an exact match. Keep aligned DKIM working. A dedicated IP is not a workaround for mismatched domains. Mailjet alignment and infrastructure scope
For the optional custom Return-Path, check both the alias and SPF resolution after support activation:
dig +short CNAME bnc3.example.com
dig +short TXT bnc3.example.com
dig +short TXT bnc3.mailjet.com
Expect the configured alias to bnc3.mailjet.com and a resolvable SPF policy through that chain. Then confirm a new message actually uses the custom envelope domain; DNS alone cannot prove activation.
Troubleshooting Mailjet-specific failures
SPF and DKIM are green, but DMARC fails. Compare the actual From and DKIM d= domains. A campaign using an unreviewed sender, different key or different subdomain may not match the configuration you checked. Do not fix this by weakening the whole domain's DMARC policy.
The custom CNAME resolves, but Return-Path is unchanged. Confirm support completed activation for the exact sending key. Test a newly generated message, not an old message whose headers cannot change after delivery.
Regenerate Key is unavailable. Mailjet requires validation of the whole domain for key regeneration, not only an individual address. Complete domain validation if a rotation is actually needed; coordinate DNS and signing changes rather than repeatedly creating new keys. Key-regeneration prerequisite
One message passes and another fails. Group samples by API key, From domain and application. A single successful newsletter does not validate transactional templates or another account. Record the failing route before changing a shared record.
Publish DMARC without weakening existing protection
Inspect the From domain's policy and any applicable inherited parent policy first. Preserve established enforcement, reporting destinations and subdomain settings. Do not create a child p=none record merely to bypass a parent's protection.
Only for a domain with no established or inherited policy and an approved monitoring rollout, this is a starter template:
Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
For From example.com, the relative owner is _dmarc in that zone. For From news.example.com, a deliberate domain-specific policy belongs at _dmarc.news.example.com, entered as _dmarc.news in the parent zone or _dmarc in a separately hosted news.example.com zone. Check inherited protection before adding it.
Replace the domain and reporting mailbox with a working destination you control or one explicitly supplied by your reporting service. Keep semicolons between tags and mailto: before the address. External destinations require the authorization check described in RFC 9990, section 4; obtain the reporting service's required setup before expecting reports. Publish one DMARC policy at the intended owner. p=none requests monitoring, not quarantine or rejection of failures.
Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.
DMARC passes when SPF or DKIM passes and aligns with From. Relaxed alignment permits an organizational-domain match; strict alignment requires an exact domain match. Review reports across all legitimate senders before stronger enforcement. RFC 9989 replaces RFC 7489 and removes pct; do not design a new rollout around that obsolete percentage tag. Current DMARC standard
Verify DNS and trusted receiver evidence separately
Replace the example names before running read-only checks:
dig +short NS example.com
dig +short TXT example.com
dig +short TXT mailjet._domainkey.example.com
dig +short TXT _dmarc.example.com
Check the authoritative answer and a recursive resolver if results differ. For this TXT-based DKIM route, expect the complete account-issued public key at the selector owner. Expect only one SPF policy at each evaluated owner. Recursive SPF evaluation must stay within the ten DNS-lookup-causing-term limit; counting the includes visible in the top-level record is insufficient. SPF evaluation rules
Send a newly generated message through each production route to a mailbox where you can inspect raw headers. Use the receiving system's trusted Authentication-Results, not an arbitrary earlier field a sender could have inserted. Record spf, smtp.mailfrom, dkim, header.d, and dmarc with header.from; obtain the selector from DKIM-Signature when needed. Authentication-Results trust boundary
Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.
Success means the actual message has an aligned passing authentication path and the trusted receiver reports dmarc=pass for the intended From domain. A DNS lookup cannot prove this. Preserve a redacted sample, route and timestamp; do not upload confidential message bodies to public tools. Authentication also does not guarantee inbox placement or eliminate reputation, consent and content problems.
For this branded-DKIM deployment, require the intended provider signature itself to have trusted dkim=pass and a d= domain aligned with the intended unchanged visible From under effective adkim, plus the trusted receiver’s dmarc=pass for that From. A DMARC pass through SPF alone does not complete the DKIM task. DMARC alignment. Diagnose the actual smtp.mailfrom result independently: fail or softfail calls for checking the connecting sender against the approved authorization; temperror is a transient evaluation failure, often DNS; permerror requires checking malformed or duplicate policies and the evaluated lookup budget. An aligned DKIM pass does not repair these SPF faults. Do not change an unrelated apex policy to fix a provider-controlled envelope domain. SPF result definitions.
If Google Workspace also sends as your domain, review EmailAuth's guide to Workspace aliases and secondary-domain alignment separately. Keep both providers authorized; completing this service's setup does not validate your mailbox route.
Review scope and implementation boundary
No customer account was configured, DNS changed or delivery test performed for this guide. Before deployment, complete the account, DNS and message checks above for your sending route. Authentication does not guarantee delivery.