Meltwater SPF, DKIM and DMARC setup, step by step

To authenticate Meltwater Media Intelligence newsletters and outreach, confirm your Approved Sender, open that account’s Configure Domain page, and publish its complete CNAME set in public DNS. Meltwater documents six CNAMEs: two for SPF-related records and four for DKIM. Wait for domain verification, then check an actual newsletter or outreach message at an external recipient. Confirming the email address alone does not authenticate the domain. Meltwater’s domain-verification instructions

The IT reference displays an update of 17 June 2026 and Approved Sender guidance 15 January 2026; those publisher dates are separate from this check. This guide is based on public documentation. No customer account, DNS configuration, test send or received message was tested in preparing it. The checks below are actions for your authorized administrator to perform.

Choose the Meltwater sending route first

This procedure covers the Approved Sender and domain-verification workflow for Media Intelligence newsletters, media pitches and press releases. It does not automatically cover Klear, a connected-mailbox integration, or system notifications sent from Meltwater-owned domains.

Meltwater distinguishes user-generated mail from system-generated digests, exports and alerts. Its IT reference says outreach requires an Approved Sender, while newsletters can use an Approved Sender or Meltwater’s own newsletter address. A digest arriving successfully therefore tells you little about whether your branded pitch authenticates. Meltwater’s documented mail categories

Before starting, agree on the intended From address, account administrator, DNS administrator and monitored reply mailbox. If several Meltwater accounts share the domain, list them individually. An account-specific record set must not be mistaken for an organization-wide authorization.

Prepare access and preserve existing DNS

You need an administrator who can manage Approved Senders, access to the sender’s mailbox for confirmation, and permission to modify the domain’s authoritative public DNS. The authoritative DNS host may differ from the company that registered the domain or hosts its website.

Use a business domain you control. Meltwater does not let you verify public mailbox domains such as Gmail or Yahoo because you cannot publish their DNS records. If New Email Account is missing, check administrator access rather than trying to solve the issue in DNS. Approved Sender prerequisites

Export the existing zone or save the affected records before making changes. Include existing SPF, DMARC, DKIM selectors and any record at a proposed CNAME owner. Record who owns those entries. Do not replace the website, mail-exchange records or another sender’s key to make room for Meltwater.

Confirm the sender and retrieve all six CNAMEs

1. In Meltwater, open Account > Approved Senders.
2. Select New Email Account, enter the sender details and continue. The documented second step displays domain-verification information that can be shared with your authorized IT administrator.
3. In the sender’s mailbox, open the confirmation message and complete Confirm Email. This verifies control of that address.
4. For an existing activated sender with an unverified domain, select Configure Domain beside the relevant domain.
5. Save the complete owner, type, target and TTL list from that account’s verification page. Do not substitute another organization’s records or values from a screenshot.

These are separate milestones: address confirmed, DNS records published, domain verified, and a delivered message authenticated. Meltwater’s Approved Sender guide describes address confirmation and record retrieval; its IT reference specifies the six-CNAME requirement.

The native record-page screenshot is cropped and masks the values; it is not a complete deployment packet. The full IT reference, not the number of rows visible in that image, establishes the six-record requirement. The six CNAMEs are not six TXT records, and the two SPF-related entries do not authorize publishing two SPF policies at the same DNS name. If your current account supplies a materially different set, have Meltwater confirm the account and sending mode before proceeding.

Publish the CNAME records safely

Create each record with the exact type and target shown. A DNS editor may want only the relative host label, whereas another accepts the fully qualified name. If it appends the zone automatically, entering the full name can create a doubled suffix such as host.example.com.example.com. Check the resulting public name, not just what the editor displays. Meltwater explicitly warns about this error and requires public rather than private DNS. CNAME configuration FAQ

The following owner examples demonstrate DNS zone mapping only. Replace ISSUED_SELECTOR with each selector from your actual account; never infer a selector or target from these placeholders.

For an illustrative SPF-related owner ISSUED_LABEL.news.example.com, use ISSUED_LABEL.news in the parent zone or ISSUED_LABEL in the delegated child. It does not belong in the _domainkey zone. Confirm every full owner and preserve existing NS delegations; the account supplies the actual labels and targets. DKIM DNS discovery

For each proposed owner:

• Confirm that it belongs to the domain and account being configured.
• Preserve underscores and account-specific characters exactly.
• Check for an existing CNAME, TXT, A or other conflicting record. An ordinary CNAME cannot share its owner with other ordinary data. Do not delete a working entry without identifying its dependency. DNS alias rules
• If there is a collision, request a supported alternative from Meltwater. Its IT reference recognizes conflicts with other applications using its third-party sender.
• With Cloudflare, keep required authentication aliases DNS only and unflattened. Turn off the affected record’s Flatten control where available and ensure applicable zone settings do not suppress the literal issued CNAME answers. Flatten-all overrides per-record settings; coordinate any shared change and assess other dependencies first. Mandatory apex or same-zone flattening may have no off switch. If it cannot preserve the required alias answer, stop and agree a supported configuration with the DNS host and Meltwater. Preserve delegated zones rather than removing NS records. Cloudflare flattening controls and CNAME verification guidance

Do not create a generic Meltwater SPF include at the root domain. This documented workflow delegates provider-managed SPF-related data through CNAMEs. It is not an instruction to replace your existing corporate SPF policy.

Where a separately confirmed route genuinely requires an SPF TXT edit, retain one SPF policy at that evaluated owner, preserve other authorized senders and validate the complete evaluation chain. RFC 7208 limits evaluation to ten DNS-dependent terms, including nested evaluation: include, a, mx, ptr, exists and redirect. It is not a budget of ten visible includes. Preserve the intended final all qualifier and redirect-only control flow. Any all mechanism makes redirect ignored, irrespective of qualifier; do not append all to a redirect-only policy or concatenate two whole policy strings. Qualifiers do not guarantee the receiving system’s final disposition. SPF redirect precedence SPF record selection and limits

Verify the domain without confusing it with sender confirmation

Return to Approved Senders and check the domain status after publication. Meltwater documents a possible 24–48-hour delay before the domain becomes verified. Compare authoritative DNS immediately if you suspect a typo; waiting will not repair the wrong owner or target. Meltwater verification timing

Additional Approved Senders on the same verified domain within the same account do not normally need the IT setup repeated. However, Meltwater separately says that multiple accounts using the same domain need CNAME information for each account. Keep those situations distinct and obtain support help if their required owners collide. Same-domain senders, multiple-account requirement

A local allowlist can change how your company receives mail. It neither publishes authentication for external recipients nor proves DMARC alignment. Use receiving-policy changes only to address a diagnosed receiving problem, not to conceal an unauthenticated sender.

Understand SPF, DKIM and DMARC for the actual message

SPF evaluates the SMTP envelope sender, normally recorded as the delivered Return-Path and reported as smtp.mailfrom. It does not evaluate the display name, Reply-To or the visible From address. For a null reverse-path, SPF uses the HELO identity. SPF identities

DKIM identifies its signing domain with d= and its selector with s=. The corresponding public key is discovered at selector._domainkey.signing-domain, following any CNAME delegation. A published selector proves that a key is available, not that your selected newsletter used it. DKIM verification

DMARC requires either an aligned SPF pass or an aligned DKIM pass. Relaxed alignment allows the same organizational domain; strict aspf=s or adkim=s requires an exact match for that mechanism. Thus, a bounce domain under example.com may align with From example.com in relaxed mode but not strict SPF mode. For a concrete DKIM example, visible From press@example.com with a passing d=news.example.com aligns in relaxed mode, assuming the same Organizational Domain, but not strict mode. A passing intended d=example.com signature aligns in both modes. These examples are hypothetical, not observed Meltwater identities. A passing signature from an unrelated provider domain does not supply aligned DKIM. Current DMARC alignment rules

Preserve an established DMARC policy and its approved reporting destinations. Do not replace p=reject with p=none merely because a new pitch fails. Authenticate the route or pause it. Only when no direct or applicable inherited policy exists at all, including p=none, may the domain owner approve a first monitoring policy such as this illustration. Check policy discovery first and agree a monitoring plan before publication:

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

In the example.com zone, the relative owner for _dmarc.example.com is _dmarc. This is not a Meltwater-generated record. For a From domain news.example.com, the full owner is _dmarc.news.example.com: enter _dmarc.news in the parent example.com zone or _dmarc in the delegated news.example.com zone. Do not place it under a delegated _domainkey namespace. Publish one DMARC policy per owner. Replace the example mailbox address after the existing mailto: prefix with a provisioned, approved destination, without duplicating that prefix.

When the report destination belongs to a different Organizational Domain from the policy domain, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain is excepted; a different hostname alone is not enough to require it. Obtain any required authorization from the reporting service rather than guessing it. RFC 9990 section 4 This protocol check is separate from the domain owner’s data-sharing approval: review the recipient, privacy, access and retention before sending reports. p=none does not guarantee delivery. Review all legitimate senders before enforcement. In particular, RFC 9989 requires domains publishing p=reject to apply valid DKIM signatures rather than rely solely on SPF. DMARC interoperability, aggregate-report destination checks

Run public DNS checks and route-specific acceptance tests

These commands are templates, not observed results. Replace every uppercase placeholder with the exact value from your record inventory. AUTH_NS means an authoritative nameserver for the relevant DNS zone. Repeat the CNAME queries for all six owners.

dig NS YOUR_DNS_ZONE +short
dig @AUTH_NS GENERATED_CNAME_OWNER CNAME +noall +answer
dig @1.1.1.1 GENERATED_CNAME_OWNER CNAME +noall +answer
dig @1.1.1.1 GENERATED_CNAME_TARGET TXT +noall +answer
dig @1.1.1.1 _dmarc.YOUR_FROM_DOMAIN TXT +noall +answer

Expect each owner to resolve to the target issued for this account. Follow additional aliases as needed to find the SPF policy or DKIM public key. Multiple component strings in a DKIM TXT answer concatenate without inserted spaces into one logical TXT record; they are not independent keys. Preserve the complete tagged value and character order. DKIM TXT representation If short output is empty, rerun without the display filters and inspect the response status. NXDOMAIN, an empty answer and SERVFAIL are different conditions. A recursive cache may lag the authoritative answer.

For a From subdomain, an empty _dmarc lookup does not automatically mean no DMARC policy applies: inspect policy discovery and the applicable parent policy. Preserve the receiver’s evaluated policy and alignment evidence rather than inventing a new subdomain policy. DMARC policy discovery

After domain verification, have an authorized sender send harmless content through each intended newsletter and outreach workflow to controlled internal and external mailboxes. Meltwater itself recommends both recipient types. Do not use a system digest or sender-activation email as the acceptance sample.

Read Authentication-Results added by your trusted receiving system, not an arbitrary upstream header. Keep private message content out of public analyzers and share only approved, redacted evidence with support. Authentication-Results trust boundary

An aligned SPF pass can satisfy DMARC, but missing or failing branded DKIM still warrants repair in this DKIM-enabled setup. Conversely, an aligned DKIM pass can preserve DMARC when forwarding breaks SPF. Compare a direct external message before diagnosing a forwarded copy. Authentication does not guarantee inbox placement.

Decide whether this route is ready

For this branded DKIM-enabled setup, accept the route only when the intended branded DKIM signature passes and aligns, the trusted receiver reports DMARC pass, and the observed From identity is correct. Reject a rewritten provider From as successful authentication of the intended brand, even when the rewritten identity passes. This operational acceptance bar is stricter than DMARC’s minimum rule, which can be satisfied by either aligned mechanism.

Inspect SPF independently even if aligned DKIM supplies DMARC pass. An SPF pass that is unaligned is an identity-design observation, not an SPF failure; record it and confirm the intended envelope configuration. Actual fail, softfail, permerror or temperror needs investigation of the real envelope domain, authorization and DNS evaluation. A passing DKIM result does not repair an SPF error. Resolve the problem or record an explicitly accepted, understood route-specific exception before rollout. Do not broaden SPF authorization indiscriminately.

To establish which authentication result is trustworthy, confirm with the receiving mail administrator or provider documentation where authentication is evaluated and how externally supplied Authentication-Results fields are stripped or distinguished. A familiar authserv-id, a convincing hostname or its position near the top of the message alone is not sufficient proof of origin. If that trust boundary is unknown, keep the result unverified and request receiver-side evidence. RFC 8601 forged-header precautions

Troubleshoot and recover without widening access

Meltwater’s IT troubleshooting reference specifically calls out duplicate hosts, multiple accounts and Mimecast 550 errors. It does not establish that every 550 response has the same cause.

If a change breaks the route, pause the affected send, compare the approved DNS diff and restore only the known-good entries or sender configuration involved. Retain keys needed by queued messages and other accounts. Do not remove the domain’s DMARC policy, disable receiving protections broadly, or copy third-party private keys. Retest the same route after a repair, rollback, sender-domain change or key rotation.