What you have is a many to many relationship. And this is a classic design challenge for any relational database. A mailing list will typically list many contacts and a given contact can be a member of many different mailing lists.
This issue is typically resolved by using a third "join" table between your two other tables, contacts and MailingLists, in your case.
In MailingLists, BTW, you will have one record for each different mailing list.
You'd have these relationships:
Contacts::ContactID = Contact_MailingLists::ContactID
MailingLists::MailingListID = Contact_MailingList::MailingListID
Here's a Demo file that illustrates a number of different ways to work with such a setup in FileMaker. It matches Contacts to Events, but by exchanging a mailing list table for the Events table, you'll have what I am describing here: http://www.4shared.com/file/dZ0bjclw/ManyToManywDemoWExtras.html
Thank you for your response. Using the third joining table, what would you suggest is the best way to assign people to the mailing list. I would like to be able to do this when accessing the information on the contact. Is this best done through a tick box/radio button, or perhaps to add them through a portal?
Did you download and look at the demo file?
It illustrates several different methods for selecting records in order to establish the needed links. One of them works from what looks like a check box list, and you can select contacts from the checkbox list for the current 'event' by clicking a check box and can click the check box a second time to remove that contact. Such a portal of contacts could be set up with a portal filter to make it easier to find and add specific contacts or groups of contacts to a mailing list. (The portal filter would be an expression that references one or more fields on the layout where you'd enter or select criteria that then control how the filter evaluates to control which records appear in the portal.)