How to Set Up SPF, DKIM and DMARC for Mailjet (2026)

Mailjet is a cloud email sending and marketing platform used by businesses to send transactional and bulk email. If your domain sends through Mailjet without proper SPF, DKIM, and DMARC records, those messages are vulnerable to spoofing and more likely to land in spam. By the end of this guide you will have all three authentication layers published in DNS and verified as passing.

Before you begin

• Edit access to your domain's DNS zone (via your registrar or DNS host — Cloudflare, Route 53, GoDaddy, etc.)
• Admin access to your Mailjet account with a verified sending domain
• The ability to send a test email from that domain and view full message headers
• Any existing SPF record for your domain copied and ready to edit — you must merge, not add a second TXT record

Step 1: Identify what's sending from Mailjet

Mailjet routes outbound email through a pool of shared and dedicated sending IPs depending on your plan. If you use Mailjet for both transactional email (via their SMTP relay or Send API) and marketing campaigns, both traffic types will originate from Mailjet's infrastructure under your domain. Before editing DNS, confirm which domain (or subdomain) appears in your From: header for each sending use case. If you send transactional mail from notifications@your-domain.com and campaigns from hello@your-domain.com, both share the same root domain and a single SPF/DMARC policy applies to both. If Mailjet has provisioned a dedicated subdomain for you (for example, a bounce-handling subdomain), that subdomain will need its own DNS records — check your Mailjet account's sender domain settings to confirm the full list of domains you need to cover.

Step 2: Add the SPF include

Mailjet publishes its sending IP ranges behind an SPF include mechanism. You need to add that include to your domain's existing SPF TXT record — or create one if none exists. Based on Mailjet's published documentation, the include string to use is include:spf.mailjet.com. Verify this value against Mailjet's current DNS setup guide before publishing, as vendors occasionally change their SPF infrastructure.

Before — an existing SPF record with another provider already included:

your-domain.com. IN TXT "v=spf1 include:_spf.google.com ~all"

After — Mailjet's include merged in:

your-domain.com. IN TXT "v=spf1 include:_spf.google.com include:spf.mailjet.com ~all"

Rules to follow when editing:

• There must be exactly one SPF TXT record on your root domain. Adding a second v=spf1 record instead of merging into the existing one will cause an SPF permerror.
• Keep ~all (softfail) or -all (hardfail) at the end. Do not remove it.
• Do not duplicate an include that is already present.

SPF 10-lookup limit warning: Every include:, a:, and mx: mechanism counts toward SPF's hard limit of 10 DNS lookups per evaluation. Mailjet itself may chain additional includes internally. If your record already references Google Workspace, Microsoft 365, Salesforce, Zendesk, and other senders, you may be near or over the limit before adding Mailjet. An SPF permerror caused by exceeding 10 lookups will cause SPF to fail as if no record exists. Use an SPF lookup counter tool to check your current count after merging.

Step 3: Enable DKIM in Mailjet

DKIM requires you to publish a public key as a DNS TXT record under a selector subdomain, then configure Mailjet to sign outgoing mail with the corresponding private key. The general workflow is as follows:

1. Log in to your Mailjet account and navigate to the sender domain management area. In Mailjet's interface this is typically found under Account Settings → Sender domains & addresses (verify the current menu path in your account, as UI labels change between product versions).
2. Locate the domain you want to authenticate and look for a DKIM setup or DNS authentication option.
3. Mailjet will generate a DKIM key pair and display the public key value you need to publish in DNS. Copy the full TXT record value — it is a long Base64-encoded string beginning with v=DKIM1; k=rsa; p=.
4. Mailjet's selector naming convention is not universally fixed across plans and configurations. Your Mailjet dashboard will show you the exact selector name to use (for example, a string like mailjet or an account-specific identifier). Do not guess the selector — copy it exactly from the interface.
5. In your DNS provider, create the following TXT record, substituting the selector name and key value shown in Mailjet:

<selector>._domainkey.your-domain.com. IN TXT "v=DKIM1; k=rsa; p=<your-public-key-value>"

A concrete example of what a published DKIM record looks like (with a placeholder key):

mailjet._domainkey.your-domain.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GN..."

Important notes for publishing the DKIM key:

• If the key value is longer than 255 characters, some DNS providers require it to be split into multiple quoted strings within the same TXT record. The format looks like "first255chars" "remainingchars". Check whether your DNS provider handles this automatically or requires manual splitting.
• After publishing, return to the Mailjet dashboard and use its built-in DNS verification button (if available) to confirm that Mailjet can resolve and read the record you just published. DNS propagation can take a few minutes to a few hours.
• Do not delete or rotate the DKIM key without generating a replacement first — key rotation without overlap will break DKIM signing for any in-flight messages.

Step 4: Publish your DMARC record

DMARC ties SPF and DKIM together under a policy that receiving mail servers enforce. Start with p=none — a monitoring-only policy — for a minimum of 14 days before advancing to p=quarantine or p=reject. This gives you time to collect aggregate reports and confirm that all legitimate sending sources are authenticated before you apply a blocking policy.

Publish the following TXT record at _dmarc.your-domain.com:

_dmarc.your-domain.com. IN TXT "v=DMARC1; p=none; adkim=r; aspf=r; rua=mailto:dmarc-rua@dmarcbusta.pro; ri=86400"

Field reference for this record:

Once you have reviewed at least two weeks of aggregate reports and confirmed that SPF and DKIM are passing consistently across all your Mailjet traffic, advance the policy in stages: p=quarantine first, then p=reject.

Step 5: Verify it works

Before sending a test email, confirm your DMARC record actually published. Use our free DMARC Checker to look up _dmarc.your-domain.com and verify the record is live, has the correct policy (p=none, quarantine, or reject), and is configured for aggregate reporting. While you are there, run the SPF Checker against your domain to make sure the SPF lookup tree is clean — once both records check out, the live email test below will give you the final confirmation.

DNS propagation for new records typically completes within 30–60 minutes, though it can take up to 48 hours in some configurations. Once you believe the records are live, use the following process to confirm:

1. Send a test message through Mailjet from your authenticated domain to a Gmail or Yahoo Mail inbox you control.
2. Open the message in Gmail. Click the three-dot menu → Show original. In Yahoo Mail, use More → View raw message.
3. At the top of the raw message, look for the Authentication-Results header. It will look similar to this:

Authentication-Results: mx.google.com;
  spf=pass (google.com: domain of sender@your-domain.com designates 1.2.3.4 as permitted sender)
  dkim=pass header.i=@your-domain.com header.s=mailjet
  dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=your-domain.com

What each result means in this context:

• spf=pass — The sending IP used by Mailjet is authorized in your SPF record. The MAIL FROM domain matched your SPF include.
• dkim=pass — The message was signed by Mailjet using the private key that corresponds to the public key you published in DNS, and the signature is intact.
• dmarc=pass — At least one of SPF or DKIM passed and the authenticated domain is aligned with the From: header domain. This is the result that matters for deliverability and policy enforcement.

If any of the three show fail or none, proceed to the next section before progressing your DMARC policy beyond p=none.

Common errors with Mailjet

• Duplicate SPF TXT records. Adding a brand-new v=spf1 include:spf.mailjet.com ~all record instead of merging the include into your existing SPF record creates two v=spf1 entries, which causes an immediate permerror. SPF allows only one record per domain. Always edit, never add a second.
• Wrong selector in DNS. Publishing the DKIM key under a selector name that does not exactly match what Mailjet is using to sign will produce a dkim=fail result. Copy the selector string character-for-character from your Mailjet dashboard — do not guess or abbreviate it.
• DKIM public key truncated or malformed. Long DKIM keys (2048-bit) exceed the 255-character limit of a single DNS TXT string. If your DNS provider does not automatically handle the split, the published key will be unreadable and DKIM will fail. Confirm with your DNS provider whether splitting is handled automatically or must be done manually.
• SPF lookup count exceeded. Adding include:spf.mailjet.com to a record that already references many SaaS providers can push you over the 10-lookup limit. The result is an SPF permerror, which DMARC treats as an SPF failure. Audit your total lookup count after every change.
• From header misalignment. DMARC alignment requires that the domain in the From: header matches (or is a subdomain of, under relaxed alignment) the domain authenticated by SPF or DKIM. If Mailjet is sending from a bounce address or subdomain that doesn't align with your visible From: domain, DMARC will fail even if SPF and DKIM individually pass. Check the Return-Path and DKIM d= values in your raw headers to confirm alignment.

How DMARC Busta helps

The steps above represent a one-time manual configuration. In practice, email infrastructure changes — Mailjet updates its SPF infrastructure, you add new sending tools, a DKIM key needs rotation — and manual DNS records fall out of date. Managing this across multiple domains compounds the problem.

DMARC Busta's Autopilot mode is designed to manage DMARC policy progression automatically, advancing domains from p=none through p=quarantine to p=reject based on aggregate report analysis rather than manual review. SPF Auto-Repair handles delegation and sending source management to keep SPF records within the 10-lookup limit as your sending stack changes. The platform's managed DMARC reporting is built to handle aggregate data at scale — designed to manage 10,000+ domains — making it practical for MSPs and enterprises that cannot review per-domain XML reports manually. Instead of repeating the steps in this guide for every domain you manage, DMARC Busta is designed to maintain that configuration continuously.

Start your free trial and put your email authentication on autopilot.