Sender Domains and Email Authentication
Your sender domain is what inbox providers learn to trust. Authentication proves that your email delivery service is allowed to send email for your domain.
Overview
A sender domain is the domain in the From email address that subscribers see. In newsletter@example.com, the sender domain is example.com. In team@updates.example.com, the sender domain is updates.example.com. Subscribers learn to recognize this domain.
An email also includes domains that subscribers usually do not see. The return-path domain receives delivery failure messages. The DKIM signing domain appears in the email headers as d=example.com. These hidden domains matter because inbox providers use them to check whether the visible sender domain is connected to the system that sent the email.
Email authentication provides that proof. SPF lists the servers that may send email for a domain. DKIM adds a signature from a domain. DMARC checks whether SPF or DKIM passed for a domain that matches the visible From domain. That match is called DMARC Alignment.
In a good setup, the visible sender domain, DKIM signing domain, and return-path domain work together. For example, if subscribers see newsletter@example.com, a healthy setup might sign with DKIM d=example.com and use a return-path such as bounce.example.com. Both domains are clearly related to example.com.
In a weak setup, email often sends through your email delivery service's default identity. The email may pass authentication for the service's domain, but that authenticated domain may not match the domain subscribers see. This is why a message can show SPF pass or DKIM pass and still fail DMARC.
You usually choose the main domain, such as example.com, or a sending subdomain, such as mail.example.com or updates.example.com. A subdomain is often safer for marketing because it separates campaign mail from employee inbox mail while keeping the brand connection clear.
Consistency is the important part. If each campaign uses a different From domain, inbox providers cannot build a stable sending history for one domain. Choose the sender domain carefully, authenticate it with your email delivery service, and keep using it for the same subscriber group.
What to Do
- Choose your domain or subdomain that subscribers should see in the From email address.
- Open your email delivery service and complete its domain verification flow for your domain or subdomain.
- Add every DNS record that the service gives you. These records usually include DKIM records, a return-path or bounce record, and sometimes tracking records.
- Add a DMARC record for the visible From domain, or review the existing record and confirm that your domain has a valid DMARC policy.
- If your email delivery service offers a custom return-path or bounce domain, set it up so SPF can align with your domain.
- Create or update the Email Delivery Connection in Mailrith with the same From domain.
- Send a real test email to Gmail, Outlook, or another inbox where you can inspect the original message headers.
- Inspect the test message headers. Confirm that DKIM passes with your domain, or SPF passes with your return-path domain, and that at least one passing method aligns with the From domain.
- Use that same sender domain consistently in Mailrith broadcasts, sequences, and automations.
What to Check
- Use a domain or subdomain you control for serious sending. Do not use free personal inbox domains for campaigns.
- DMARC protects the visible From domain. That domain must match the domain used for SPF alignment or DKIM alignment.
- The DKIM
d=domain should usually be your domain or a subdomain of your domain. - The return-path domain should be your domain or a subdomain of your domain if you want SPF to help DMARC alignment.
- Set up your email delivery service's DNS records before you send campaigns. Do not wait until the campaign is ready and then discover that the sender domain is not verified.
- Use the same sender domain for the same subscriber group whenever possible.
- Do not treat an email delivery connection as fully ready until SPF, DKIM, DMARC, and alignment pass in a real test message.
- Use a subdomain such as
mail.example.comorupdates.example.comwhen you want marketing mail separated from day-to-day employee email.
Fix Common Issues
Invalid Sender Domain
A sender domain checker cannot read the sender domain because the domain field is empty, contains a full URL, includes extra path text, or is not a real domain.
- Enter only your domain, such as
example.comormail.example.com. - Remove
https://, page paths, spaces, and email display names. - If you copied an email address, keep only the part after
@. - Run the sender domain check again with the cleaned domain.
- Use the same cleaned domain when you configure the Mailrith delivery connection and your email delivery service's domain authentication.
Sender Domain Basics
A sender domain check found that your domain exists, but you still need to confirm that Mailrith uses the same domain that is authenticated in your email delivery service.
- Open the Mailrith delivery connection that sends from your domain.
- Confirm that the From email address uses your recognizable sender domain.
- Open your email delivery service and confirm that the same domain or sending subdomain is verified.
- Check SPF, DKIM, DMARC, and alignment for your domain. Success means SPF or DKIM passes and at least one passing method aligns with the From domain.
- Send a real test email and inspect the message headers. Confirm that the headers show authentication passing for your domain.
Note
Mailrith can use the sender identity you choose, but your email delivery service and DNS control the actual authentication. If alignment is failing, fix your domain setup in that service first.