Sending Domains, SPF and DKIM

Every campaign you send must come from a domain you control and must be authenticated. Mailbox providers such as Gmail, Outlook and Yahoo check authentication on every message, and unauthenticated bulk mail is rejected or filed as spam regardless of its content.

This guide covers adding a sending domain, publishing the records it requires, and confirming it works.

Never send from a free mailbox address

Your From address must be on a domain you own, for example news@yourdomain.com.

Sending campaigns with a From address at gmail.com, outlook.com, yahoo.com or any other free provider will fail DMARC alignment. Those providers publish policies instructing receivers to reject mail sent on their behalf by anyone else, and that includes us. There is no configuration that works around this.

Step 1: add the sending domain in MailWizz

1. In your customer area, go to Domains, then Sending domains
2. Choose Create new
3. Enter your domain, for example yourdomain.com
4. Save

MailWizz generates a DKIM key pair and shows you the DNS record to publish. Leave this page open, you need the value in step 2.

Step 2: publish the DKIM record

MailWizz shows a TXT record. Publish it exactly as shown at your DNS provider.

Type: TXT
Name: mailer._domainkey.yourdomain.com.
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhki...
TTL: 3600

Copy the value exactly. DKIM keys are long and many DNS interfaces wrap or truncate them. After publishing, compare the published value against the one MailWizz shows, character for character. A single altered character makes the signature fail, and the failure is silent.

Some DNS providers require the name without the domain suffix, so mailer._domainkey rather than mailer._domainkey.yourdomain.com. Check how your provider handles other records before assuming.

Step 3: publish the SPF record

SPF lists which servers may send mail for your domain. Publish this single TXT record at your domain root:

Type: TXT
Name: yourdomain.com.
Value: v=spf1 mx include:_spf.protectedserver.net ~all
TTL: 3600

The include covers our entire sending platform, so if we ever change or add sending infrastructure your record keeps working with no action from you. The mx term keeps mail sent directly from your own mailbox server working.

Use the include, not individual IP addresses. If you list our sending IPs by hand, your authentication breaks silently the day our infrastructure changes. The include is maintained by us and updates automatically.

You may only have one SPF record per domain. If you already have one, merge the terms into it rather than adding a second. Two SPF records is a configuration error and causes authentication to fail entirely.

Step 4: publish a DMARC record

DMARC tells receiving providers what to do when authentication fails, and gives you reporting.

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

Start with p=none, which enforces nothing and simply collects reports. Once the reports show your legitimate mail passing consistently, you can tighten to p=quarantine and later p=reject.

The rua address receives aggregate reports. Point it at a mailbox you actually read, because those reports are how you find out that something is sending as your domain.

Step 5: verify

Back in MailWizz, open your sending domain and choose Verify. It checks that the published DKIM record matches the key it generated.

DNS changes take time to propagate. If verification fails immediately after publishing, wait for your TTL to expire and try again before assuming something is wrong.

Once verified, the domain shows as verified and signing is active. Every campaign sent from an address on that domain is then DKIM signed automatically.

Checking your work

Send a campaign test to an address you control at a different provider, then inspect the message headers.

In Gmail, open the message, click the three dots menu and choose Show original. You want to see:

SPF:   PASS
DKIM:  PASS
DMARC: PASS

If any of the three does not pass, do not start sending campaigns. Fix the authentication first. Every message sent while authentication is broken damages your domain reputation, and that damage takes far longer to repair than it takes to cause.

Common problems

DKIM fails but the record looks correct. The published value has been altered, usually by a DNS interface that added quotes, split the value, or trimmed whitespace. Compare character for character with what MailWizz shows.

SPF passes on your own mail but fails on campaigns. You probably have the record at the wrong name, or you have two SPF records. There must be exactly one, at the domain root.

DMARC fails while SPF and DKIM pass. This is an alignment problem. The domain in your From address must match the domain being authenticated. Sending as news@marketing.yourdomain.com while authenticating yourdomain.com is the usual cause.

If you are stuck, open a ticket and include the full Show original output from a test message. That tells us in one step what several rounds of questions otherwise would.