Verify an application domain in MailKite
Separate application mail from employee mail, verify the domain, and create a scoped sending or receiving connection.
Reviewed
Use a domain or subdomain you control for application mail. Decide whether MailKite should send, receive, or do both before publishing DNS; moving a mailbox domain’s MX records changes where new incoming mail goes.
Configure the domain
- Add the domain in the dashboard, or select an available hosted receiving subdomain for a receiving workflow.
- For sending, publish the exact SPF/DKIM records supplied for that domain and complete the displayed verification checks. Merge SPF requirements rather than creating multiple SPF records at one DNS name.
- For receiving on your own domain, publish the required MX record only for the domain/subdomain assigned to this workflow.
- Create a credential with the permissions needed by the application. Keep it in a backend secret manager, not browser code.
Sending verification and receiving routing are different gates. A verified sender does not prove that an exact-address webhook route is configured.
Confirm the boundary
Check the dashboard’s verified state, then run one controlled send or direct incoming test. Record the actual domain, route, and message identifier. If verification stays pending, inspect authoritative DNS before repeatedly changing records.
For an existing Exchange/Gmail mailbox, keep its MX records intact and use an explicitly approved forwarding destination instead. Domain ownership does not authorize reading an employee’s mailbox.
Continue with sending or signed receiving in this section. See domain setup, DNS instructions, and authentication for the authoritative product contract.