> ## Documentation Index
> Fetch the complete documentation index at: https://docs.introw.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Email Domain

> Set up a custom sending domain, add the DNS records, and verify so partner notifications send from your own address in Introw.

**Open in Introw:** [Portal settings](https://app.introw.io/settings/portal)

## How it works

You choose a sender, a display name and a local part, on a domain you control, such as Acme Partners \<[partners@mail.acme.com](mailto:partners@mail.acme.com)>. Introw generates the DNS records that authenticate the domain, and you add them at your DNS provider. Once those records verify, Introw sends every partner notification from your address instead of the default Introw sender.

The authentication is **DKIM** (a TXT record that signs your mail) and a **return-path** (a CNAME that routes bounces and aligns the domain). Mailbox providers trust authenticated mail, which is what keeps it out of spam. There is no separate SPF record to add; the verified return-path handles alignment.

Two behaviors matter in practice:

* **Verification is the switch.** Until a domain is verified, notifications keep sending from the default Introw address, so partners are never blocked while DNS propagates. The moment verification completes, sends move to your address.
* **Nothing else changes.** Verifying a domain only changes the From address. Every existing notification, channel, segment, and reply-by-email setting stays exactly as configured, so there is nothing to migrate or reconfigure.

Replies still route the way each notification is configured; where a notification has no specific sender to reply to, replies fall back to the default Introw address.

## Email authentication and SPF

Three standards decide whether mailbox providers trust your mail: **SPF**, **DKIM**, and **DMARC**. Introw sets all three up through the two DNS records above, which is why **you never add an SPF record yourself**. This is by design, not a gap - here is how each one is handled.

* **SPF is checked against the return-path, not the From address.** Mailbox providers validate SPF against the return-path domain (the address that collects bounces), not the address partners see. The return-path CNAME you add points at Introw's sending infrastructure, which already publishes the SPF record that authorizes the servers your mail is sent from. So SPF passes automatically, with no record for you to maintain.
* **The return-path aligns SPF with your domain for DMARC.** Because the return-path lives on your own sending domain (a subdomain of, for example, mail.yourcompany.com), it shares an organizational domain with the From address. That shared domain is exactly what DMARC's SPF alignment check looks for, so DMARC-aligned SPF passes as well.
* **DKIM is aligned too, as a second layer.** The DKIM record signs your mail on your own domain. DMARC only requires SPF **or** DKIM to align, so notifications still pass DMARC in the forwarding cases where SPF can break.

<Note>
  You never add an SPF record for Introw, and there are two places people are tempted to add one - neither works:

  * **On the return-path subdomain** - you can't. A DNS host that holds a CNAME cannot also hold a TXT record, and the return-path is already a CNAME. That CNAME is what carries SPF, so no TXT belongs there.
  * **On your root domain** - it has no effect. SPF is checked against the return-path, not your root domain, so an `include` for Introw there does nothing for this mail - and it still counts against SPF's ten-lookup limit, which can break SPF for the rest of your mail.

  The return-path CNAME is the only record needed for SPF.
</Note>

## Prerequisites

* A plan that includes the email domain add-on. Orgs without it are prompted to upgrade.
* Admin access to portal settings.
* A domain you can send from, such as mail.yourcompany.com.
* Access to your DNS provider to add records. Adding them may require your IT team or whoever manages the domain's DNS, so loop them in early.

## Settings & configuration

Email domain is configured from [Portal settings](https://app.introw.io/settings/portal), next to the portal custom domain.

### Sender

**Sender display name** is the friendly name partners see in their inbox, such as Acme Partners. Set it to the name partners recognize.

**Sender address** is the local part and domain the mail sends from, such as [partners@mail.acme.com](mailto:partners@mail.acme.com). The local part is the bit before the @ (for example, partners or notifications); the domain is the one you will authenticate.

You can update the display name and sender address later without re-verifying the domain.

### DNS records

Introw generates the records to add at your DNS provider:

* **DKIM record** - a TXT record that signs your outbound mail so mailbox providers can confirm it is really from you.
* **Return-path record** - a CNAME that routes bounce handling and aligns the sending domain.

Add each record exactly as shown. DNS changes can take time to propagate before verification succeeds.

### Verification

Once the records resolve, verify the domain in Introw. When both the DKIM and return-path records check out, the domain is marked verified and partner notifications start sending from your address.

### Removing the domain

Remove the email domain to stop sending from it; notifications fall back to the default Introw sender.

## Setup walkthrough

<Steps>
  <Step title="Open Portal settings">
    Go to [Portal settings](https://app.introw.io/settings/portal) and open the email domain configuration.
  </Step>

  <Step title="Set the sender">
    Enter the sender display name and address you want partners to see.
  </Step>

  <Step title="Add the DNS records">
    Copy the DKIM and return-path records into your DNS provider exactly as shown.
  </Step>

  <Step title="Verify">
    Wait for DNS to propagate, then verify the domain in Introw.
  </Step>

  <Step title="Confirm the sender">
    Trigger a partner email and confirm it arrives from your address.
  </Step>
</Steps>

## How-to guides

<CardGroup cols={2}>
  <Card title="Send notifications from your own domain" icon="book-open" href="/features/portal/email-domain/guides/send-notifications-from-your-own-domain">
    Set your sender, add the DNS records Introw generates, and verify so partner notifications send from your own authenticated address instead of the default Introw one.
  </Card>
</CardGroup>

## Limits & gotchas

<Warning>
  DNS changes can take time to propagate, so verification may not succeed immediately. Notifications only send from your domain after verification; until then they use the default Introw sender, so partners keep receiving mail. Verifying changes only the From address: existing notification settings are untouched.
</Warning>

## Troubleshooting

* **Verification keeps failing** - the DNS records have not propagated yet or were entered incorrectly. Confirm the DKIM and return-path records match exactly, then verify again.
* **Emails still come from the Introw address** - the domain is not verified yet, so sends use the default sender until verification completes.
* **Replies are not going where expected** - replies route per notification; where none is set, they fall back to the default Introw address. See [Configure partner notifications by email](/features/partners/notifications/guides/configure-partner-notifications-by-email).
* **A DMARC report shows SPF as failing or unaligned** - your domain's DMARC policy is likely set to strict SPF alignment. The return-path is on a subdomain, so it aligns under relaxed alignment (the DMARC default) but not strict. Aligned DKIM keeps DMARC passing either way. See the FAQ below.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Do I need to add an SPF record for Introw?">
    No. SPF is validated against the return-path domain, and the return-path record you add already resolves to Introw's SPF-authorized infrastructure. The DKIM and return-path records are the complete setup.
  </Accordion>

  <Accordion title="A DMARC report shows SPF failing or misaligned. Is something broken?">
    Usually not. If your DMARC policy uses strict SPF alignment (`aspf=s`), it flags the return-path as misaligned because it sits on a subdomain rather than the exact From domain. This does not affect delivery: aligned DKIM keeps DMARC passing. For SPF to align as well, use relaxed alignment (`aspf=r`), which is the DMARC default.
  </Accordion>

  <Accordion title="Can I add Introw to our existing SPF record instead of the return-path record?">
    No. An SPF include on your root domain applies to a domain that is not used as the return-path, so it has no effect on mail sent through Introw, and it consumes one of SPF's ten allowed DNS lookups. Add the return-path CNAME exactly as shown instead.
  </Accordion>

  <Accordion title="Will this change SPF for our normal company email (Google Workspace, Microsoft 365)?">
    No. Your mailbox provider sends from your root domain and still needs its own SPF record - keep it exactly as it is. Introw only adds a DKIM TXT record and a return-path CNAME on a dedicated sending subdomain, so it never touches the SPF record your mailbox relies on.
  </Accordion>

  <Accordion title="What DMARC policy should we use?">
    Any policy works, including `p=reject`, as long as SPF alignment is relaxed (`aspf=r`, the default). Because Introw sets up aligned DKIM, partner notifications pass DMARC even under an enforcing policy.
  </Accordion>
</AccordionGroup>