# DNS records (SPF, DKIM, DMARC)

> The SPF, DKIM, and DMARC records MailBlastr generates for a domain, what each one does, and how to publish them.

When you add a domain, MailBlastr returns a set of DNS records to publish at your DNS provider. They authenticate your mail so mailbox providers trust it: **DKIM** cryptographically signs every message, **SPF** authorizes the sending servers, and **DMARC** tells receivers what to do and ties it together.

Each record below uses the bare domain `yourdomain.com` and a region of `us-east-1` as an example. Your actual values appear in the [`POST /domains`](https://www.mailblastr.com/docs/api/domains-create) response and in the dashboard.

## DKIM (1 TXT record)

MailBlastr generates a DKIM keypair for your domain and uses the private key to sign your mail. You publish **one** DKIM TXT record holding the public key at a fixed selector hostname. That single record must resolve for the domain to verify.

**DKIM — TXT**

| Name | Type | Required | Description |
| --- | --- | --- | --- |
| `Type` | TXT | No | A single DKIM key record. |
| `Name` | mailblastr._domainkey.yourdomain.com | No | The DKIM selector hostname. `mailblastr` is the fixed selector MailBlastr uses. |
| `Value` | v=DKIM1; k=rsa; p=<public key> | No | The RFC 6376 DKIM key record holding your domain’s public key. |
| `TTL` | Auto | No | Use your provider default; no specific TTL is required. |

Why it matters: DKIM lets receivers verify the message was sent by you and was not altered in transit. Without the DKIM TXT record resolving, verification will not finish and the domain stays `pending` (or goes `failed`).

## SPF (a MAIL FROM subdomain: MX + TXT)

MailBlastr configures a custom MAIL FROM subdomain — `send.yourdomain.com` — so the bounce/return path aligns with your domain. That subdomain needs two records:

**SPF — MX**

| Name | Type | Required | Description |
| --- | --- | --- | --- |
| `Type` | MX | No | Receives bounce and complaint feedback for the MAIL FROM subdomain. |
| `Name` | send.yourdomain.com | No | The custom MAIL FROM subdomain. |
| `Value` | feedback-smtp.us-east-1.amazonses.com | No | Region-specific feedback host. The region matches your domain’s configured region. |
| `Priority` | 10 | No | MX priority. |
| `TTL` | Auto | No | Provider default. |

**SPF — TXT**

| Name | Type | Required | Description |
| --- | --- | --- | --- |
| `Type` | TXT | No | SPF policy for the MAIL FROM subdomain. |
| `Name` | send.yourdomain.com | No | The custom MAIL FROM subdomain (same host as the MX). |
| `Value` | v=spf1 include:amazonses.com ~all | No | Authorizes MailBlastr to send for the MAIL FROM subdomain. |
| `TTL` | Auto | No | Provider default. |

Why it matters: SPF lets receivers confirm the message came from a server allowed to send for your MAIL FROM domain. The MX record routes bounce and complaint notifications back to MailBlastr. Note the SPF host value embeds the **configured region** (`us-east-1` above) — see [Choosing a region](https://www.mailblastr.com/docs/domains/region).

## DMARC (1 TXT record)

**DMARC — TXT**

| Name | Type | Required | Description |
| --- | --- | --- | --- |
| `Type` | TXT | No | DMARC policy record. |
| `Name` | _dmarc.yourdomain.com | No | The standard DMARC hostname. |
| `Value` | v=DMARC1; p=none; | No | A monitoring (`p=none`) policy to start with. Tighten to `quarantine` or `reject` once you trust your alignment. |
| `TTL` | Auto | No | Provider default. |

Why it matters: DMARC ties SPF and DKIM together with a published policy and tells receivers how to treat mail that fails authentication. MailBlastr starts you at `p=none` (monitor only) so legitimate mail is never blocked while you confirm everything aligns; you can raise the policy later at your DNS provider.

## Publishing and propagation

Add every returned record exactly as MailBlastr generated it — copy and paste the host and value rather than retyping, since a single wrong character (or a trailing dot your provider adds automatically) will stop verification. The records must match what the [`POST /domains`](https://www.mailblastr.com/docs/api/domains-create) response shows.

When the records are published correctly, a domain often verifies within **15 minutes**. DNS changes can occasionally take up to **72 hours** to propagate globally, so a domain may sit at `pending` for a while. If it has not verified after 72 hours, double-check the records and [re-verify](https://www.mailblastr.com/docs/api/domains-verify).

> **Note:** DNS changes can take time to propagate — anywhere from a few minutes to several hours depending on your provider and TTLs. If a domain stays `pending` after you publish the records, wait and then [re-verify](https://www.mailblastr.com/docs/api/domains-verify).